System, method and program product for generating and utilizing stable value digital assets

ABSTRACT

The present invention generally relates to the use of a stable value digital asset to pay dividends for securities and other financial instruments tied to a blockchain.

REFERENCE TO RELATED APPLICATIONS

The present application claims priority to and benefit of U.S.Provisional Patent Application Ser. No. 62/660,655, filed Apr. 20, 2018entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZINGSTABLE VALUE DIGITAL ASSETS and also claims priority to and the benefitof U.S. Provisional Patent Application Ser. No. 62/647,353, filed Mar.23, 2018 entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING ANDUTILIZING STABLE VALUE DIGITAL ASSETS and further claims priority to andthe benefit of U.S. Provisional Patent Application Ser. No. 62/638,679,filed Mar. 5, 2018 entitled SYSTEM, METHOD AND PROGRAM PRODUCT FORGENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, the entire contentof each of which is hereby incorporated by reference herein.

FIELD

The present invention generally relates to the use of a stable valuedigital asset to pay dividends or other payments for securities andother financial instruments or investments tied to a blockchain. Inembodiments, the present invention relates to specific applications ofstable value digital asset tokens tied to a blockchain.

BACKGROUND

In recent times, using blockchain technology and/or tokens to trackinventory, including potentially, equities or shares in a fund has beena subject of a lot of discussion. However, current blockchaintechnology, as implemented, does not have adequate technologicalsolutions to paying dividends or other forms of payouts (like interest)on such investments in a stable value token which is tied to ablockchain technology.

Accordingly, it would be beneficial to provide for a method and systemthat provide for making payments on digital assets that avoid theproblems discussed above.

SUMMARY

An object of the present invention is to address technologicalchallenges that currently exist in paying, e.g., dividends, on digitalassets tied to a blockchain technology. In embodiments, the presentinvention may be used to make other payments such as interest androyalties to name a few.

This and other objects shall be addressed by embodiments of the presentinvention as set forth herein.

The present invention generally relates to the use of stable valuedigital assets as a crypto currency that can be linked to other digitalassets using block chain technology. In embodiments, the presentinvention relates to specific applications of stable value digital assettokens tied to a blockchain.

A stable value digital asset token (e.g., SVCoin) is provided which canbe pegged to a fiat currency such as USD, Euro, Yen, to name a few. Forexample, 1 SVCoin will have a net asset value (NAV) of $1. UnlikeBitcoin and many other crypto protocols, the SVCoin will not have anatural cap (e.g., 22 million bitcoins) and because it is pegged to afiat currency, it will not fluctuate in value against such fiat currencyas is typical of many crypto currencies.

In embodiments, the SVCoin can be issued by a trusted entity, like adigital asset exchange, bank or other trusted entity using a token on anestablished blockchain, like ether or bitcoin, and smart contracttechnology. Thus, for example, a buyer can provide the trusted entity(e.g., digital asset exchange, bank, etc.) with a fixed sum of fiat(e.g., 50 USD) and in return be issued a corresponding fixed sum ofSVCoin (e.g., 50 SVCoin). In embodiments, the digital asset exchange canbe a regulated trust, such as Gemini Trust Company LLC (“Gemini”). Inembodiments, other types of trusted entities (e.g., banks, trusts, etc.)may also be used to issue, administer, redeem, and/or otherwise managethe SVCoin. In embodiments, the trusted entity (digital asset exchange,bank, etc.) can charge a processing fee for issuing the SVCoin either infiat or in a digital asset, such as the SVCoin. In embodiments, fiatdeposited to the trusted entity (e.g., digital asset exchange) aremaintained by the trusted entity on par with the amounts deposited.Thus, in embodiments, SVCoin is collateralized by fiat. SVCoin holderscan also exchange SVCoin for fiat on the same notional basis with thetrusted entity.

In embodiments, proof of control processes for the SVCoin and fiat heldby the trusted entity may also be employed to provide verified trust. Inembodiments where the trusted entity or digital asset exchange is aregulated trust, or other regulated entity, regulatory oversight caninsure that the appropriate amount of fiat is being maintained to coverthe notional amount of SVCoin issued. In embodiments, an independentauditor may be used to verify the appropriate amount of fiat is beingmaintained.

In embodiments, a method of issuing electronic payments using a stablevalue digital asset token on a digital asset security token includes thesteps of: (a) providing a digital asset security token database storedon a first set of one or more computer readable media associated with adigital asset security token issuer system associated with a digitalasset security token issuer, wherein the digital asset security tokendatabase comprises a log of digital asset security tokens including: (i)a first set of digital asset addresses including a respective digitalasset address for each respective digital asset security token holder;and (ii) a respective digital asset security token amount associatedwith each respective digital asset address, wherein each respectivedigital asset address of the first set of digital asset addresses istied to a distributed public transaction ledger maintained by aplurality of geographically distributed computer systems in apeer-to-peer network in the form of a blockchain; (b) providing a stablevalue digital asset token database stored on the distributed publictransaction ledger maintained by the plurality of geographicallydistributed computer systems in the peer-to-peer network in the form ofthe blockchain, wherein the stable value digital asset token databasecomprises a log of stable value digital asset tokens including: (i) asecond set of digital asset addresses including a second respectivedigital asset address for each respective stable value digital assettoken holder; (ii) a respective stable value digital asset token amountfor each second respective stable value digital asset token holder,wherein the stable value digital asset tokens are issued by a stablevalue digital asset token issuer using a digital asset exchange computersystem associated with a digital asset exchange; (c) receiving, by thedigital asset exchange computer system, a first request from the digitalasset security token issuer system to purchase a first sum of stablevalue digital asset tokens in exchange for a second sum of fiat, whereinthe first sum corresponds to the second sum based on a fixed notionalamount; (d) verifying, by the digital asset exchange computer system,the first request, including: (i) verifying, by the digital assetexchange computer system, that the digital asset security token issueris a registered user of the digital asset exchange; and (ii) verifying,by the digital asset exchange computer system, that the digital assetsecurity token issuer has at least the second sum of fiat available fortransaction with the digital asset exchange as reflected in a fiatledger of the digital asset exchange computer system; (e) accessing, bythe digital asset exchange computer system, the digital asset securitytoken database to determine: (i) each respective digital asset addressof the first set of digital asset addresses for each respective digitalasset security token holder; and (ii) a respective corresponding paymentamount in stable value digital asset tokens for each respective digitalasset security token holder based at least in part on the fixed notionalvalue, the first sum and respective digital asset security token amountassociated with each digital asset address of the first set of digitalasset addresses; (f) generating, by the digital asset exchange computersystem, transaction instructions for the first sum of stable valuedigital asset token by updating the stable value digital asset tokendatabase to reflect the addition of new stable value digital assettokens in the amount of the first sum and the corresponding digitalasset addresses associated with each new stable value digital assettokens; (g) transferring, by the digital asset exchange computer system,the second sum of fiat on the fiat account ledger from the user accountof the digital asset security token issuer, to a custodial account ofthe digital asset exchange associated with stable value tokens, whereinthe digital asset exchange custodial account will maintain in trust afifth amount of fiat corresponding to a sixth amount of stable valueoutstanding based on the fixed notional amount; (h) publishing, by thedigital asset exchange computer system to the blockchain, transactioninstructions associated with crediting the respective payment amount ofstable value digital asset tokens to each respective digital assetaddress of the first set of digital asset addresses; and (i) notifying,by the digital asset exchange computer system, each digital assetaddress of the first set of the digital asset addresses of eachrespective transfer of stable value digital asset tokens to eachrespective digital asset address of the first set of digital assetaddresses.

In embodiments, the blockchain may be the Ethereum blockchain.

In embodiments, the blockchain may be the Bitcoin blockchain.

In embodiments, the digital asset exchange may be a regulated digitalasset exchange.

In embodiments, the digital asset security token is a securityregistered with a government authority.

In embodiments, the digital asset security token is a debt security andthe electronic payments are interest.

In embodiments, the digital asset security token is an equity securityand the electronic payments are dividends.

In embodiments, the digital asset security token is secured byintellectual property rights and the electronic payments are royalties.

In embodiments, the blockchain may be based on an mathematical protocolfor proof of work.

In embodiments, the mathematical protocol for proof of work may be opensource.

In embodiments, the blockchain may be based on a mathematical protocolfor proof of stake.

In embodiments, the mathematical protocol for proof of stake may be opensource.

In embodiments, the blockchain may be based on a cryptographicmathematical protocol.

In embodiments, the method may include a step of publishing, by thedigital asset exchange computer system to a side ledger, the transactioninstructions associated with crediting the respective payment amount ofstable value digital asset tokens to each respective digital assetaddress of the first set of digital asset addresses and the publishingstep (h) includes publishing the transaction instructions from the sideledger to the distributed public asset ledger periodically oraperiodically.

In embodiments, the method may include steps of receiving, at thedigital asset security token issuer system, from at least one digitalasset security token holder, a payment request prior to the receivingstep (c), the payment request including: (i) the digital asset addressof the digital asset security token holder; and (ii) a request totransfer a payment amount of stable value digital asset tokens to thedigital asset address of the digitals asset security token holder;confirming, at the digital asset security token issuer system, that: (i)the digital asset address of the digital asset token holder is valid;(ii) the amount of digital asset security tokens associated with theaddress of the digital asset token holder is more than zero; and (iii)the digital asset token holder is entitled to payment; and generating,at the digital asset security token issuer system, the first requestbased at least in part on the payment request when the digital assetaddress of the digital token holder is valid, the amount of digitalasset security tokens associated with the address of the digital assettoken holder is more than zero and the digital asset token holder isentitled to payment.

In embodiments, the digital asset security token database is maintainedand stored on the plurality of geographically distributed computersystems in the peer-to-peer network in the form of a blockchain.

In embodiments, the digital asset security token database is maintainedon a sidechain, separate from the blockchain, wherein information on thesidechain is published and stored on the blockchain periodically oraperiodically.

In embodiments, the generating step (f) includes generating, by thedigital asset exchange computer system, transaction instructions for thefirst sum of stable value digital asset token by updating the stablevalue digital asset token database to reserve stable value digital assettokens in the amount of the first sum.

In embodiments, a method of issuing electronic payments using a stablevalue digital asset token on a digital asset security token includessteps of: (a) providing a digital asset security token database storedon a first set of one or more computer readable media associated with adigital asset security token issuer system associated with a digitalasset security token issuer, wherein the digital asset security tokendatabase comprises a log of digital asset security tokens including: (i)a first set of digital asset addresses including a respective digitalasset address for each digital asset security token holder; and (ii) arespective digital asset security token amount associated with eachrespective digital asset address, wherein each respective digital assetaddress of the first set of digital asset addresses is tied to adistributed public transaction ledger maintained by a plurality ofgeographically distributed computer systems in a peer-to-peer network inthe form of a blockchain; (b) providing a stable value digital assettoken database stored on the distributed public transaction ledgermaintained by the plurality of geographically distributed computersystems in the peer-to-peer network in the form of the blockchain,wherein the stable value digital asset token database comprises a log ofstable value digital asset tokens including: (i) a second set of digitalasset addresses including a second respective digital asset address foreach stable value digital asset token holder; (ii) a respective stablevalue digital asset token amount for each second respective stable valuedigital asset token holder, wherein the stable value digital assettokens are issued by a stable value digital asset token issuer using atrusted entity system associated with a trusted entity; (c) receiving,by the trusted entity system, a first request from the digital assetsecurity token issuer system to purchase a first sum of stable valuedigital asset tokens in exchange for a second sum of fiat, wherein thefirst sum corresponds to the second sum based on a fixed notionalamount; (d) verifying, by the trusted entity system, the first request,including: (i) verifying, by the trusted entity system, that the digitalasset security token issuer is a registered user of the trusted entitysystem; and (ii) verifying, by the trusted entity system, that thedigital asset security token issuer has at least the second sum of fiatavailable for transaction with the stable value digital asset tokenissuer system as reflected in a fiat ledger of the trusted entitysystem; (e) accessing, by the trusted entity system, the digital assetsecurity token database to determine: (i) each respective digital assetaddress of the first set of digital asset addresses for each digitalasset security token holder; and (ii) a corresponding payment amount instable value digital asset tokens for each digital asset security tokenholder based at least in part on the fixed notional value, the first sumand respective digital asset security token amount associated with eachdigital asset address of the first set of digital asset addresses; (f)generating, by the trusted entity system, transaction instructions forthe first sum of stable value digital asset tokens by updating thestable value digital asset token database to reflect the addition of newstable value digital asset tokens in the amount of the first sum and thecorresponding digital asset addresses associated with each new stablevalue digital asset token; (g) transferring, by the trusted entitysystem, the second sum of fiat on the fiat account ledger from the useraccount of the digital asset security token issuer, to a custodialaccount of the stable value digital asset token issuer system associatedwith stable value digital asset tokens, wherein the custodial accountwill maintain in trust a fifth amount of fiat corresponding to a sixthamount of stable value coin outstanding based on the fixed notionalamount; (h) publishing, by the trusted entity system to the blockchain,transaction instructions associated with crediting the respectivepayment amount of stable value digital asset tokens to each respectivedigital asset address of the first set of digital asset addresses; and(i) notifying, by the trusted entity system, each digital asset addressof the first set of the digital asset addresses of each respectivetransfer of stable value digital asset tokens to each respective digitalasset address of the first set of digital asset addresses.

In embodiments, the blockchain is the Ethereum blockchain.

In embodiments, the blockchain is the Bitcoin blockchain.

In embodiments, the stable value digital asset token issuer is aregulated digital asset exchange.

In embodiments, the stable value digital asset token issuer is a bank.

In embodiments, the trusted entity is a regulated digital assetexchange.

In embodiments, the trusted entity is a bank.

In embodiments, the digital asset security token is a securityregistered with a government authority.

In embodiments, the digital asset security token is a debt security andthe electronic payments are interest.

In embodiments, the digital asset security token is an equity securityand the electronic payments are dividends.

In embodiments, the digital asset security token is secured byintellectual property rights and the electronic payments are royalties.

In embodiments, the blockchain is based on an mathematical protocol forproof of work.

In embodiments, the mathematical protocol is open source.

In embodiments, the blockchain is based on a mathematical protocol forproof of stake.

In embodiments, the mathematical protocol is open source.

In embodiments, the blockchain is based on a cryptographic mathematicalprotocol.

In embodiments, the method includes a step of publishing, by the trustedentity system to a side ledger, the transaction instructions associatedwith crediting the respective payment amount of stable value digitalasset tokens to each respective digital asset address of the first setof digital asset addresses, wherein the publishing step (h) includespublishing the transaction instructions from the side ledger to thedistributed public asset ledger periodically or aperiodically.

In embodiments, the method includes the additional steps of: receiving,at the trusted entity system, from at least one digital asset securitytoken holder, a payment request prior to the receiving step (c), thepayment request including: (i) the digital asset address of the digitalasset security token holder; and (ii) a request to transfer a paymentamount of stable value digital asset tokens to the digital asset addressof the digitals asset security token holder; and confirming, at thedigital asset security token issuer system, that (i) the digital assetaddress of the digital asset token holder is valid; (ii) the amount ofdigital asset security tokens associated with the address of the digitalasset token holder is more than zero; and (iii) the digital asset tokenholder is entitled to payment; and generating, at the trusted entitysystem, the first request based at least in part on the payment requestwhen the digital asset address of the digital token holder is valid, theamount of digital asset security tokens associated with the address ofthe digital asset token holder is more than zero and the digital assettoken holder is entitled to payment.

In embodiments, the digital asset security token database is maintainedand stored on the plurality of geographically distributed computersystems in the peer-to-peer network in the form of the blockchain.

In embodiments, the digital asset security token database is maintainedon a sidechain, separate from the blockchain, wherein information on thesidechain is published and stored on the blockchain periodically oraperiodically.

In embodiments, the generating step (f) includes generating, by thetrusted entity system, transaction instructions for the first sum ofstable value digital asset tokens by updating the stable value digitalasset token database to reserve stable value digital asset tokens in theamount of the first sum.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present invention will be described withreferences to the accompanying figures, wherein:

FIG. 1 is a schematic diagram of a digital asset network in accordancewith exemplary embodiments of the present invention;

FIG. 2 is an exemplary screen shot of an excerpt of an exemplary bitcointransaction log showing digital addresses in accordance with exemplaryembodiments of the present invention;

FIG. 2A is an exemplary screen shot of a Security Token ledger inaccordance with exemplary embodiments of the present invention;

FIG. 3 is an exemplary exchange agent interface in accordance withexemplary embodiments of the present invention;

FIGS. 4A-B are schematic diagrams illustrating participants in a digitalasset exchange in accordance with exemplary embodiments of the presentinvention;

FIGS. 5A-B are schematic diagrams of exemplary exchange computer systemsin accordance with exemplary embodiments of the present invention;

FIG. 6 is an exemplary flow chart for processes for digital assetexchange account creation and account funding in accordance withexemplary embodiments of the present invention;

FIGS. 7A-B are an exemplary schematic diagram and corresponding flowchart of a process for digital asset exchange customer account fiatfunding via an exchange-initiated request in accordance with exemplaryembodiments of the present invention;

FIGS. 7C-E are an exemplary schematic diagram and corresponding flowchart of a process for digital asset exchange customer account fiatfunding via a customer-initiated request in accordance with exemplaryembodiments of the present invention;

FIGS. 8A-B are a schematic diagram and corresponding flow chart of aprocess for digital asset exchange account digital asset withdrawal inaccordance with exemplary embodiments of the present invention;

FIG. 9A is an exemplary flow chart of the process for purchasing SVCoinfor fiat on a digital asset exchange in accordance with exemplaryembodiments of the present invention;

FIG. 9B is an exemplary flow chart of the process for redeeming SVCoinfor fiat on a digital asset exchange in accordance with exemplaryembodiments of the present invention;

FIG. 10 is an exemplary flow chart of the process of sending tokens fromAlice to Bob on the Ethereum blockchain in accordance with exemplaryembodiments of the present invention;

FIGS. 11A1-4 illustrates an exemplary embodiment of a dashboard fiatinterface which allows registered users to deposit and/or withdraw fiatwith the digital asset exchange in accordance with exemplary embodimentsof the present invention;

FIGS. 11B1-4 illustrates an exemplary embodiment of a dashboard digitalasset interface which allows registered users to deposit and/orwithdrawal digital assets with the digital asset exchange system inaccordance with exemplary embodiments of the present invention;

FIGS. 11C1-2 illustrates an exemplary embodiment of a dashboard SVCoininterface which allows registered users to purchase and/or redeemSVCoins for fiat or digital with the digital asset exchange system inaccordance with exemplary embodiments of the present invention;

FIG. 11D illustrates an exemplary embodiment of a dashboard SecurityToken interface which allow Security Token issuers to provideinstructions to transfer SVCoins to Security Token holders in accordancewith exemplary embodiments of the present invention; and

FIG. 12 illustrates an exemplary process flow reflecting an exemplaryembodiment where a Security Token issuer initiates a transfer of SVCoinsto Security Token holders in accordance with exemplary embodiments ofthe present invention.

DETAILED DESCRIPTION

The present invention generally relates to the use of a stable valuedigital asset to pay dividends for securities and other financialinstruments tied to a blockchain. In embodiments, the present inventionrelates to specific applications of stable value digital asset tokenstied to a blockchain.

Digital Math-Based Assets and Bitcoin

A digital math-based asset is a kind of digital asset based upon acomputer generated mathematical and/or cryptographic protocol that may,among other things, be exchanged for value and/or be used to buy andsell goods or pay for services. A digital math-based asset may be anon-tangible asset that is not based upon a governmental rule, law,regulation, and/or backing. The Bitcoin system represents one form ofdigital math-based asset.

A bitcoin may be a unit of the Bitcoin digital math-based asset. Otherexamples of digital math-based assets include Ethereum, Ripple, Cardano,Litecoin, NEO, Stellar, IOTA, NEM, Dash, Monero, Lisk, Qtum, Zcash,Nano, Steem, Bytecoin, Verge, Siacoin, Stratis, BitShares, Dogecoin,Waves, Decred, Ardor, Hshare, Komodo, Electroneum, Ark, DigiByte,E-coin, ZClassic, Byteball Bytes, PIVX, Cryptonex, GXShares, Syscoin,Bitcore, Factom, MonaCoin, ZCoin, SmartCash, Particl, Nxt, ReddCoin,Emercoin, Experience Points, Neblio, Nexus, Blocknet, GameCredits,DigitalNote, Vertcoin, BitcoinDark, Skycoin, ZenCash, NAV Coin, Achain,HTMLCOIN, Ubiq, BridgeCoin, Peercoin, PACcoin, XTRABYTES, Einsteinium,Asch, Gas, Counterparty, BitBay, Viacoin, Rise, Guiden, ION, MetaverseETP, LBRY Credits, Crown, Electra, Burst, MinexCoin, Aeon, SaluS,DECENT, CloakCoin, Pura, ECC, DeepOnion, Groesticoin, Lykke, SteemDollars, I/O Coin, Shift, HempCoin, Mooncoin, Dimecoin, Namecoin,Feathercoin, Diamond, Spectrecoin, Filecoin and Tezos, to name a few. Inembodiments, digital math-based assets, such as bitcoin, may be acceptedin trade by merchants, other businesses, and/or individuals in manyparts of the world.

In embodiments, a digital math-based asset may be based on an opensource mathematical and/or cryptographic protocol, which may exist on adigital asset network, such as a Bitcoin network or an Ethereum network.The network may be centralized, e.g., run by one or more centralservers, or decentralized, e.g., run through a peer-to-peer network.Digital math-based assets may be maintained, tracked, and/oradministered by the network.

A digital math-based asset system may use a decentralized electronicledger system, which may be maintained by a plurality of physicallyremote computer systems. Such a ledger may be a public transactionledger, which may track asset ownership and/or transactions in a digitalmath-based asset system. The ledger may be a decentralized publictransaction ledger, which can be distributed to users in the network,e.g., via a peer-to-peer sharing. Ledger updates may be broadcast to theusers across the network. Each user may maintain an electronic copy ofall or part of the ledger, as described herein. In embodiments, adigital asset system may employ a ledger that tracks transactions (e.g.,transfers of assets from one address to another) without necessarilyidentifying the assets themselves.

In embodiments, a digital asset ledger, such as the Bitcoin blockchainor the Ethereum blockchain, can be used to achieve consensus and tosolve double-spending problems where users attempt to spend the samedigital assets in more than one transaction. In embodiments, before atransaction may be cleared, the transaction participants may need towait for some period of time, e.g., a six confirmation wait (typicallyone hour in the context of the Bitcoin network, 15 minutes in thecontext of the Litecoin network, to name a few), before feelingconfident that the transaction is valid, e.g., not a double count. Eachupdate to the decentralized electronic ledger (e.g., each addition of ablock to the Bitcoin blockchain or the Ethereum blockchain) followingexecution of a transaction may provide a transaction confirmation. Aftera plurality of updates to the ledger, e.g., 6 updates, the transactionmay be confirmed with certainty or high certainty.

In embodiments, a blockchain can be a public transaction ledger of thedigital math-based asset network, such as the Bitcoin network or theEthereum network. For example, one or more computer systems (e.g.,miners) or pools of computer systems (e.g., mining pools) can solvealgorithmic equations allowing them to add records of recenttransactions (e.g., blocks), to a chain of transactions. In embodiments,miners or pools of miners may perform such services in exchange for someconsideration such as an upfront fee (e.g., a set amount of digitalmath-based assets) and/or a payment of transaction fees (e.g., a fixedamount or set percentage of the transaction) from users whosetransactions are recorded in the block being added. In embodiments,digital assets in the form of a digital asset token, such as Gas, may beused to pay such fees.

The digital asset network (e.g., Bitcoin network or Ethereum Network)may timestamp transactions by including them in blocks that form anongoing chain called a blockchain. In embodiments, the addition of ablock may occur periodically, e.g., approximately every 15 seconds,every minute, every 2.5 minutes or every 10 minutes, to name a few. Suchblocks cannot be changed without redoing the work that was required tocreate each block since the modified block. The longest blockchain mayserve not only as proof of the sequence of events but also records thatthis sequence of events was verified by a majority of the digital assetnetwork's computing power. The blockchain recognized by the nodescorresponding to the majority of computing power, or some otherconsensus mechanism, will become the accepted blockchain for thenetwork. In embodiments, confirmation of a transaction may be attainedwith a high degree of accuracy following the addition of a fixed numberof blocks to the blockchain (e.g., six blocks) after a transaction wasperformed and first recorded on the blockchain. As long as a majority ofcomputing power (or other consensus mechanism) is controlled by nodesthat are not cooperating to attack the network, they will generate thelongest blockchain of records and outpace attackers.

There are a variety of consensus mechanisms (or protocols) that may beused to verify transactions recorded in a blockchain. A few non-limitingexamples of these mechanisms are discussed below, however, otherprotocols may be used in accordance with exemplary embodiments of thepresent invention.

For example, the proof of control protocol is one example of a consensusmechanism and is used, for example, in the Bitcoin blockchain. A moredetailed discussion of proof of control protocols can be found inco-pending U.S. patent application Ser. No. 15/920,042 filed Mar. 13,2018 entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYINGDIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, the entirecontent of which is hereby incorporated by reference herein.

The proof of stake protocol is another optional protocol that may beimplemented by blockchains. In this type of protocol, the validator'sstake is represented by the amount of digital assets held. Validatorsaccept, reject or otherwise validate a block to be added to theblockchain based on the amount of digital assets held by the Validatoron the blockchain. If the Validators are successful in validating andadding the block, such a protocol, in embodiments, will award successfulValidators are a fee in proportion to their stake.

The delegated proof of stake protocol is another protocol that isavailable and is, for example, used by the EOS blockchain. In thisprotocol, blocks are produced in a fixed number in rounds (e.g., 21 forEOS). At the start of every such round, block producers are chosen. Anumber less than all of the producers (e.g., 20 in EOS) areautomatically chosen while a corresponding number are chosenproportional to the number of their votes relative to other producers.In embodiments, the remaining producers may be shuffled using apseudorandom number derived from the block time, for example. Inembodiments, other forms of randomized selection may be used. To ensurethat regular block production is maintained, in embodiments, block timeis kept to short (e.g., 3 seconds for EOS) and producers may be punishedfor not participating by being removed from consideration. Inembodiments, a producer has to produce a minimal number of block, e.g.,at least one block every 24 hours to be in consideration. All of thenodes will, by default, not switch to a fork which does not include anyblocks not finalized by a sufficient majority (e.g., 15 of the 21producers) regardless of chain length. Thus, in EOS, each block mustgain 15 of 21 votes for approval to be considered a part of the chain.

In embodiments, a delegated byzantine fault tolerance protocol may beused as a consensus mechanism. For example, NEO uses this type ofprotocol. In this protocol, one of the bookkeeping nodes is randomlychosen as a “speaker.” The speaker then looks at all the demands of the“citizens,” (e.g., all of the holders of the digital asset), and createsa “law” (e.g., a rule governing the protocol). The speaker thencalculates a “happiness factor” of these laws to see if the number isenough to satisfy the citizen's needs or not. The speaker then passesthe happiness factor down to the delegates (e.g., the other bookkeepingnodes). The delegates may then individually check the speaker'scalculations. If the speaker's number matches the delegate's number,then the delegates give their approval, and if not, then they give theirdisapproval. In embodiments, a sufficient majority (e.g., 66% in NEO) ofthe delegates need to give their approval for the law to pass, i.e. forthe block to be added. If a sufficient majority is not obtained (e.g.,less than 66% approval), then a new speaker is chosen and the processstarts again.

Ripple uses an algorithm in which each server gathers all validtransactions that have not yet been applied and makes them public. Eachserver then amalgamates these transactions and votes on the veracity ofeach. Transactions that receive at least a minimum number of yes voteswill move into another round of voting. A minimum of 80% approval isrequired before a transaction is applied.

These and other protocols may be used to generate a blockchain inaccordance with exemplary embodiments of the present invention.

In embodiments, transaction messages can be broadcast on a best effortbasis, and nodes can leave and rejoin the network at will. Uponreconnection, a node can download and verify new blocks from other nodesto complete its local copy of the blockchain.

In the exemplary Bitcoin system, a bitcoin is defined by a chain ofdigitally signed transactions that began with its creation as a blockreward through bitcoin mining. Each owner transfers bitcoin to the nextby digitally signing them over to the next owner in a bitcointransaction which is published to and added on to a block on theblockchain. A payee can then verify each previous transaction, e.g., byanalyzing the blockchain to verify the chain of ownership.

Other examples of different types of blockchains noted above that areconsistent with embodiments of present invention pose unique problems.Certain currencies present unique challenges in that transactions and/orwallets or digital asset addresses associated therewith may be shielded(e.g., not viewable by the public on the ledger). For example, Monero isbased on the CryptoNight proof-of-work hash algorithm and possessessignificant algorithmic differences relating to blockchain obfuscation.Monero provides a high level of privacy and is fungible such that everyunit of the currency can be substituted by another unit. Monero istherefore different from public-ledger cryptocurrencies such as Bitcoin,where addresses with coins previously associated with undesired activitycan be blacklisted and have their coins refused by others.

In particular, ring signatures mix spender's address with a group ofothers, making it more difficult to establish a link between eachsubsequent transaction. In addition, Monero provides “stealth addresses”generated for each transaction which make it difficult if not impossibleto discover the actual destination address of a transaction by anyoneelse other than the sender and the receiver. Further, the “ringconfidential transactions” protocol may hide the transferred amount aswell. Monero is designed to be resistant to application-specificintegrated circuit mining, which is commonly used to mine othercryptocurrencies such as Bitcoin, however, it can be mined somewhatefficiently on consumer grade hardware such as x86, x86-64, ARM andGPUs, to name a few.

Another example of a modified blockchain consistent with exemplaryembodiments of the present invention discussed above is Darkcoin.Darkcoin adds an extra layer of privacy by automatically combining anytransaction its users make with those of two other users—a feature itcalls Darksend—so that it will be more difficult to analyze theblockchain to determine where a particular user's money ended up.

Yet another example of a modified blockchain consistent with exemplaryembodiments of the present invention discussed above is Zcash. The Zcashnetwork supports different types of transactions including:“transparent” transactions and “shielded” transactions. Transparenttransactions use a transparent address (e.g., “t-address”). Inembodiments, transactions between two t-addresses behave like Bitcointransactions and the balance and amounts transferred are publiclyvisible on the Zcash blockchain. Unlike the Bitcoin Blockchain, theZcash network may also support shielded transactions using a shieldaddress (e.g., “z-address”). In embodiments, the “z-address” providesprivacy via zero-knowledge succinct noninteractive arguments ofknowledge (e.g., “zk-SNARKS” or “zero-knowledge proofs”). The balance ofa z-address is not publicly visible on the Zcash blockchain—the amounttransferred into and out of a zaddress is private if between twoz-addresses—but may be public if between a z-address and a t-address.

In embodiments, a digital asset based on a blockchain, may in turninclude special programming, often referred to as “smart contracts”,which allow for the creation of “tokens”, which in turn are digitalassets based on digital assets. In embodiments, tokens may be ERC-20tokens, and used in conjunction with ERC-20 token standard as aprogramming language. In embodiments, other protocols may be usedincluding but not limited to ERC-223 and ERC-721, to name a few. Inembodiments, smart contracts may be written on other smart contracts toprovide for increased functionality. One non-limiting example of thistype of structure is the open source Cryptokittens game in which digitalkittens are provided as ERC-721 tokens with a series of smart contractsprovided to define how the kittens will interact with each other andwith users. In embodiments, programming modules may be added to and/ortransferred with programming modules associated with specific tokens. Byway of illustration, a first token, e.g., a Cryptokitten Tiger, maypurchase a second token, e.g., a digital “hat,” that will then becomeassociated with the first token to be a Tiger with a hat, and remainwith the first token when transferred. Thus, by way of illustration, inthe context of example embodiments of the present invention, the firsttoken could be, e.g., a security token, and the second token could be,e.g., an account holding SVCoins, or a right to request SVCoins fromanother account as discussed below. If the first token is transferred,the second token would transfer with the ownership of the first token.

For example, digital assets can include tokens, which like other digitalassets that can represent anything from loyalty points to vouchers andIOUs to actual objects in the physical world. Tokens can also be tools,such as in-game items, for interacting with other smart contracts. Atoken is a smart contract running on top of a blockchain network (suchas the Ethereum Blockchain, the Bitcoin Blockchain, to name a few). Assuch, it is a set of code with an associated database. In embodiments,the database may be maintained by an issuer. In embodiments, thedatabase may be included as part of the blockchain. In embodiments, theledger may be maintained in the first instance as a database in asidechain by the issuer or agent of the issuer and subsequentlypublished and stored as part of a blockchain. The code describes thebehavior of the token, and the database is basically a table with rowsand columns tracking who owns how many tokens.

If a user or another smart contract within the blockchain network (suchas the Ethereum Network) sends a message to that token's contract in theform of a “transaction,” the code updates its database.

So, for instance, as illustrated in FIG. 10, using a token based on theEthereum Network for illustration purposes, when a wallet app sends amessage to a token's contract address to transfer funds from Alice toBob, the following proceed occurs.

In step S1001, at the token issuer computer system, Security Tokens arecreated. In embodiments, each Security Token may have a “ECR20 ContractWallet Address” (“Contract Address”) which is used to write a smartcontract. In embodiments, the smart contract may include instructions toperform at least: (1) token creation, (2) token transfer, (3) tokendestruction; and (4) updating smart contract coding. In embodiments, theContact Address may be associated with a designated cold storage walletassociated with the token issuer. In embodiments, the Contract Addressmay be associated with a designated hot storage wallet associated withthe token issuer. In embodiments, the Contract Address may be associatedwith a designated cold storage wallet associated with the token issuer,but may also give at least some permission to perform operations by oneor more hot wallets associated with the token issuer and/or a tokenadministrator on behalf of the token issuer. Security Tokens may becreated in batches (for example, 100,000 SVCoins worth $100,000 U.S.dollars) in the “Contract Wallet” or Contract Address and later moved toa hot wallet or associates digital asset address for transactions asnecessary. In embodiments, a Security Token database is maintained in ablockchain, such as the Ethereum blockchain, for example. Inembodiments, the ledger may be maintained in the first instance as adatabase in a sidechain by the issuer or agent and subsequentlypublished and stored as part of a blockchain. In embodiments, SecurityTokens may be generated on the fly, however, in this case, the ContractWallet may be associated with a hot wallet, or a Supplementary Walletauthorized to perform such operations may be used, and may be a hotwallet with the Contract Wallet remaining a cold wallet. A more detaileddiscussion of hot wallets and cold wallets is presented in U.S. Pat. No.9,892,460 issued Feb. 13, 2018 entitled SYSTEMS, METHODS, AND PROGRAMPRODUCTS FOR OPERATING EXCHANGE TRADED PRODUCTS HOLDING DIGITALMATH-BASED ASSETS, the entire content of which is incorporated herein.In embodiments, Contract Wallets may be maintained by the SVCoin issuerand which would hold the private key associated with the token on anassociated device. In embodiments, Contract Wallets may be provided on auser computer device and hold the private key associated with the token.In such embodiments, a user computer device may include a softwareapplication to provide secure access to the token issuer such that theuser can engage in transactions.

By way of illustration, an ECR20 Contract can include the followingrepresentative type of functions as shown in Table 1 in its programmingof a Smart Contract associated with a particular token, such as asecurity token:

TABLE 1  1 //------------------------------------------------------------------------- 2 // ERC Token Standard #20 Interface  3 //https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md  4 //------------------------------------------------------------------------- 5 contract ERC20Interface {  6 function total Supply( ) public constantreturns (uint);  7 function balanceOf (address tokenOwner) publicconstant returns (uint balance);  8 function allowance (addresstokenOwner, address spender) public constant returns (uint remaining); 9 function transfer (address to, uint tokens) public returns (boolsuccess); 10 function approve (address spender, uint tokens) publicreturns (bool success); 11 function transferFrom (address from, addressto, uint tokens) public returns (bool success); 12 13 event Transfer(address indexed from, address indexed to, uint tokens); 14 eventApproval (address indexed tokenOwner, address indexed spender, uinttokens);

Some of the tokens may include further information describing the tokencontract such as shown Table 2:

TABLE 2 1 string public constant name = “Token Name”; 2 string publicconstant symbol = “SYM”; 3 uint8 public constant decimals = 18; // 18 isthe most common number of decimal places

In Step S1002, Alice's wallet, or associated digital asset address, maysend a request message to the database maintained by the blockchainincluding: (a) Alice's ethereum digital asset address, which istypically associated with a digital wallet (Source Address); (b) tokenidentification information; (c) amount of token to be transferred; and(d) Bob's ethereum digital asset address (Destination Address). Inembodiments, if a fee is charged for the transaction, fee paymentinformation may also be required and provided. For example, on theEthereum network, an amount of Gas tokens may be required from thesender to pay for processing of the transaction into a block on theblockchain. In embodiments, the message may include a proposed feeamount and/or fee proposal including a limit in e.g., Gas. The requestmessage will also be digitally signed by Alice's private key.

In Step S1004, when miners on the blockchain receive the transactionrequest directed to the contract wallet or associated digital assetaddress, with the request message, miners on the blockchain will confirmthe transaction, including verifying that the message was properlysigned by Alice. In Step S1004-b, the miners may verify that Alice hassufficient amount of tokens to perform the requested transaction, forexample, by comparing Alice's balance against Alice's token balance asindicated on the blockchain. In Step S1004-c, the validity of Bob'sdigital asset address (the Destination Address) may also be confirmed bythe miners. The miners may also compare the request with smart contractcoding and instructions included in the Contract Address. Thetransaction fee discussed above is paid to the miners for confirming thetransaction as noted above.

In Step S1006, if the request is verified the transaction is publishedin the Security Token database of the blockchain reflecting a debitagainst Alice's token holdings and a corresponding credit to Bob's tokenholdings (less any applicable fees).

In Step S1008, response messages to the digital asset addresses of bothAlice and Bob may be sent to reflect that the transaction wassuccessfully processed. In embodiments, such messages may includeinformation including: (i) the source digital asset address; (ii) thedestination digital asset address; (iii) the amount of tokenstransferred; and/or (iv) the new balances for each digital asset addressor associated digital wallet. In embodiments, the message may include aproposed fee amount and/or fee proposal including a limit in e.g., Gas.In embodiments, Alice, Bob, and/or third parties may view the balancesand transaction information based on the information stored in theblockchain, by, e.g., viewing token balances at websites likeetherscan.io, to name a few.

In contrast to tokens, a blockchain based digital asset (such as ether)is hard coded into the blockchain (e.g., the Ethereum Blockchain)itself. It is sold and traded as a cryptocurrency, and it also powersthe network (e.g., the Ethereum Network) by allowing users to pay forsmart contract transaction fees. (In some networks, transactions feesmay be paid for in digital assets, such as tokens (e.g., Gas) orblockchain based digital assets (e.g., bitcoin). In the EthereumNetwork, all computations typically have a cost based on other digitalassets, such as Gas.

In embodiments, when tokens are sent to or from a Contract Address, forexample, a fee may be charged for that transaction (in this case, arequest to the token's contract to update its database) in, e.g., someform of digital asset, such as ether, bitcoin, Gas, to name a few. Inembodiments, the message may include a proposed fee amount and/or feeproposal including a limit in digital asset, e.g., ether, bitcoin orGas. This payment is then collected by a miner who confirms thetransaction in a block, which then gets added to the blockchain.

FIG. 2 is an exemplary screen shot of an excerpt of a bitcointransaction log or transaction ledger 115 showing digital asset accountidentifiers (e.g., addresses) corresponding to origin and destinationaccounts for each transaction and amount information for eachtransaction in accordance with exemplary embodiments of the presentinvention. The exemplary log 115 includes transaction identifiers, dateand/or time information, fee information, digital asset accountidentifiers for the origin accounts, digital asset account identifiersfor the destination accounts, and amounts transferred to and from eachaccount. Such a ledger may also include description information (such asnotes describing a transaction, e.g. “rent payment”) and/or balanceinformation, to name a few. Other forms of transaction logs can be usedconsistent with exemplary embodiments of the present invention. In anexemplary embodiment, the description information may be included as amessage in a request for a transaction. The description informationdiscussed above thus may also be used to confirm control of over aparticular account.

As can be seen in FIG. 2, currency transfers may begin from a singleorigin and be sent to a single destination or multiple destinations.Similarly, currency may be transferred from multiple origins to one ormore destinations.

FIG. 2A illustrates a screenshot showing an exemplary embodiment of atoken ledger for a Gas token. This particular screenshot shows aspecific example the token ledger for the Gas token provided byetherscan.io. As illustrated the ledger illustrates, in chronologicalorder, a series of transactions identifying the source address 2202 anddestination address 2204 along with the quantity of tokens 2206transferred in each transaction. In embodiments, the Security Tokenledger of the present application may be similar to that illustrated inFIG. 2A. In embodiments, as illustrated in FIG. 2A, the Security Tokenledger may also include the option to identify all Token holders 2208 aswell as options to view token details 2210 and to view the contractdetails 2012. Similarly, in embodiments, an SVCoin Token ledger of thepresent application may be similar to that illustrated in FIG. 2A.Digital asset ledgers may be maintained in the form of a database. Sucha database may be maintained on a blockchain or off a blockchain as asidechain which may later be published to the blockchain.

An exemplary embodiment of a digital asset network is illustrated inFIG. 1. In embodiments, other digital math-based assets can bemaintained and/or administered by other digital math-based assetnetworks. Without meaning to limit the invention, a digital math-basedasset network will be discussed with reference to a Bitcoin network byexample. Of course, other digital asset networks, such as the Ethereumnetwork can be used with embodiments of the present invention. A digitalmath-based asset network, such as a Bitcoin network, may be an online,end-user to end-user network hosting a public transaction ledger 115 andgoverned by source code 120 comprising cryptologic and/or algorithmicprotocols. A digital asset network can comprise a plurality of endusers, a . . . N, each of which may access the network using one or morecorresponding user device 105 a, 105 b, . . . 105N. In embodiments, userdevices 105 may be operatively connected to each other through a datanetwork 125, such as the Internet, a wide area network, a local areanetwork, a telephone network, dedicated access lines, a proprietarynetwork, a satellite network, a wireless network, a mesh network, orthrough some other form of end-user to end-user interconnection, whichmay transmit data and/or other information. Any participants in adigital asset network may be connected directly or indirectly, asthrough the data network 125, through wired, wireless, or otherconnections.

In the exemplary embodiment, each user device 105 can run a digitalasset client 110, e.g., a Bitcoin client, which can comprise digitalasset source code 120 and an electronic transaction ledger 115. Thesource code 120 can be stored in processor readable memory, which may beaccessed by and/or run on one or more processors. The electronictransaction ledger 115 can be stored on the same and/or differentprocessor readable memory, which may be accessible by the one or moreprocessors when running the source code 120. In embodiments, theelectronic transaction leger 115 a (contained on a user device 105 a)should correspond with the electronic transaction ledgers 115 b . . .115N (contained on user devices 105 b . . . 105N), to the extent thatthe corresponding user device has accessed the Internet and been updated(e.g., downloaded the latest transactions). Accordingly, the electronictransaction ledger may be a public ledger. Exemplary embodiments ofdigital asset clients 110 for the Bitcoin network (Bitcoin clients)include Bitcoin-Qt and Bitcoin Wallet, to name a few.

Stable Value Coin Digital Asset Token

In embodiments, a stable value digital asset token (“SVCoin”) mayoperate on a blockchain based network, such as the Ethereum network, adecentralized virtual currency and blockchain network with a programminglanguage that can automatically facilitate, verify, and enforce theterms of a digital contract entered into by human or computercounterparties. In embodiments, the SVCoin may conform with the ERC-223token standard, making it available for a variety of uses within theEthereum Network. In embodiments, the SVCoin may conform to the ERC-721token standard. However, unlike other types of cryptocurrenciescurrently available on the Ethereum Network or the virtual currencyecosystem generally, the SVCoin will be strictly pegged to a fiatcurrency, such as the U.S. Dollar, and a custodian, such as a trustedentity like a digital asset exchange or bank, to name a few, will holdan equal value in fiat (e.g., one (1) SVCoin is pegged to be equal toone (1) USD).

In embodiments, a digital asset exchange, such as a regulated digitalasset exchange, like Gemini, may be the sole issuer of the SVCoin. Inembodiments, especially in the context of a regulated digital assetexchange, in order to obtain freshly minted SVCoin, customers must firstregister with the digital asset exchange and create an exchange accountto allow access to the digital asset exchange platform. Customers maydeposit fiat (e.g., USD) with the digital asset exchange, via, e.g.,Fedwire, ACH, Swift, to name a few, into the customers respectiveexchange account, or convert into fiat some or all of existing digitalassets held at the digital asset exchange. SVCoin may be held in thecustomer's exchange account or may be transferred via the blockchain,such as via the Ethereum Network. In embodiments, the SVCoin issuer maybe a digital asset exchange, a bank, a trust or some other trustedentity, to name a few.

In embodiments, regardless of whether the SVCoin is stored in thecustomer's exchange account or transferred via the blockchain such asthe Ethereum Network, the digital exchange will continue to holdsufficient fiat to maintain the total value of SVCoin based on anotional pegged rate (e.g., one USD for every one SVCoin issued). Inembodiments, fiat will be held in a segregated, omnibus bank account atone or more federally insured depository institution.

In embodiments, customers wishing to redeem their SVCoin for fiat may doso through the digital asset platform. Customers that have transferredtheir SVCoin to the blockchain will be able to transfer their SVCoinback to their exchange account, and subsequently redeem them for fiatthrough the digital exchange platform, such as via Fedwire, ACH or SWIFTto the Customer's registered bank account, to name a few. For each fiatredeemed with the digital exchange, a corresponding SVCoin will beremoved from circulation. As discussed above, exemplary embodiments ofsuch transactions are discussed in connection with FIGS. 11A1-4, 11B1-4and 11C1-2.

Blockchain Based Financial Instrument

In embodiments, a digital asset in the form of a token (“SecurityToken”) may be issued to represent inventory, equity interests in aventure, real estate, rights in intellectual property such music,videos, pictures, to name a few. When used as a security, appropriatefilings with a regulatory authority may be necessary to comply withlocal law. In the case of a security, investors may exchange fiat orother digital assets (such as bitcoin or ether, to name a few) inexchange for Security Tokens. Typically, Security Tokens may issue usinga smart contract written on another digital asset (such as ether orbitcoin, to name a few), and tracked in a separate database stored in adistributed peer to peer network in the form of a blockchain. In anexample, the blockchain is the Ethereum Blockchain and includes allSecurity Tokens, the respective address associated therewith, whereinmaintenance of the blockchain is controlled by contract instructionsstored in the form of a smart contract at the Contract Address. Inembodiments, the Secure Token database maintained on the blockchain maybe viewed via etherscan.io. In embodiments, the Security Token ledgermay be maintained as a sidechain in a separate database off chain andpublished periodically or aperiodically to the blockchain. Each SecurityToken may also be associated with a specific digital asset address onthe network associated with the underlying digital asset (e.g., theEthereum Network when ether is the underlying digital asset, or theBitcoin Network, when bitcoin is the digital asset, to name a few).Generally, the same blockchain will be used for the SVCoin and theSecurity Token.

Digital Asset Exchange

In embodiments, one form of trusted entity that may be an issuer ofSVCoin or an agent of the issuer is a digital asset exchange or bank. Inembodiments, the trusted entity may maintain an SVCoin database on ablockchain. In embodiments, the trusted entity may maintain the SVCoindatabase off chain as a sidechain which may be periodically oraperiodically published to a blockchain as discussed elsewhere.

In some embodiments, the trusted entity may be a digital asset exchange.A digital asset exchange, such as a digital math-based asset exchange,may allow users to sell digital assets in exchange for any other digitalassets or fiat currency and/or may allow users to sell fiat currency inexchange for any digital assets. Accordingly, an exchange may allowusers to buy digital assets in exchange for other digital assets or fiatcurrency and/or to buy fiat currency in exchange for digital assets. Inembodiments, a digital asset exchange may integrate with a foreignexchange market or platform. A digital asset exchange may be configuredas a centralized exchange or a decentralized exchange, as discussedherein.

In embodiments, the issuer of the SVCoin may be a digital assetexchange, a bank, a trust, or other trusted entity. In the context wherea digital asset exchange may act as an issuer for SVCoin, or as an agentof the issuer, a digital asset exchange computer system may maintain aledger as one or more databases associated with the SVCoin. Such adatabase may include an electronic log of all transactions, includingthe source wallet, the destination wallet, the timestamp of thetransaction, the amount of the transaction (e.g., the number of SVCoin),and/or the balance in each wallet before and/or after the transaction.In embodiments, the database may include a list of wallet addresses andbalances in each wallet of the SV Coin. In embodiments, the issuer maymaintain the database by using a smart contract in association with aContract Digital Address as part of a blockchain network, such as theEthereum Network. In embodiments, the ledger may be maintained in adatabase as a sidechain which is periodically, or aperiodically,published to a blockchain such as the Ethereum blockchain. Inembodiments, the ledger may be maintained directly on the blockchain.

FIG. 3 is a schematic diagram illustrating various potentialparticipants in a digital asset exchange, in exemplary embodiments. Theparticipants may be connected directly and/or indirectly, such asthrough a data network 15, as discussed herein. Users of a digital assetexchange may be customers of the exchange, such as digital asset buyersand/or digital asset sellers. Digital asset buyers may pay fiat (e.g.,USD, Euro, Yen, to name a few) in exchange for digital assets (e.g.,bitcoin, ether, litecoin, dogecoin, to name a few). Digital assetsellers may exchange digital assets (e.g., bitcoin, ether, litecoin,dogecoin, to name a few) for fiat (e.g., USD, Euro, Yen, to name a few).In embodiments, instead of fiat, other forms of digital assets may alsobe used.

In embodiments, users may connect to the exchange through one or moreuser electronic devices 3202 (e.g., 3202-1, 3202-2, . . . , 3202-N),such as computers, laptops, tablet computers, televisions, mobilephones, smartphones, and/or PDAs, to name a few. A user electronicdevice 3202 may access, connect to, and/or otherwise run one or moreuser digital wallets 3204. In embodiments, buyers and/or sellers mayaccess the exchange using their own electronic devices and/or through adigital asset kiosk. A digital asset enabled kiosk can receive cash,including notes, coins or other legal tender, (of one or more fiatcurrencies) from a buyer to use in buying a quantity of digital assets.A digital asset kiosk may dispense cash (of one or more fiat currencies)to a seller of digital assets. In embodiments, a digital asset kiosk mayreceive funds from and/or dispense funds to a card, such as a prepaid orreloadable card, digital asset address associated with a digital wallet,or electronic account. In embodiments, a digital wallet may be stored ona user electronic device, such as a mobile electronic device, or othercomputing device.

Users may also have user bank accounts 3208 held at one or more banks3206. In embodiments, users may be able to access their bank accountsfrom a user electronic device 3202 and/or from a digital wallet 3204 ordigital address associated therewith.

A digital asset exchange computer system 3210 can include softwarerunning on one or more processors, as discussed herein, as well ascomputer-readable memory comprising one or more database. A digitalasset exchange can include one or more exchange digital wallets 3212,e.g., digital wallet 3212-A. Exchange digital wallets may be used tostore digital assets in one or more denominations from one or moreparties to a transaction. In embodiments, exchange digital wallets maystore digital assets owned by the exchange, which may be used where anexchange is a counter-party to an exchange transaction, which can allowexchange transactions to occur even when a buyer and a seller are nototherwise both available and in agreement on transaction terms.

A digital asset exchange may have one or more bank accounts, e.g., bankaccount 3216-A, held at one or more banks 3214, such as exchange banksor exchange partner banks, which are banks associated with and/or inpartnership with the exchange. In embodiments, exchanges may accessother repositories for fiat currency. An exchange bank account may be apass-through account that receives fiat currency deposits from a digitalasset buyer and transfers the fiat currency to a digital asset seller.The exchange bank account may hold money in escrow while an exchangetransaction is pending. For example, the exchange bank account may holda digital asset buyer's fiat currency until a digital asset sellertransfers digital assets to the buyer, to an exchange, or to anauthorized third party. Upon receipt by the appropriate recipient of therequisite amount of digital assets, the exchange may authorize therelease of the fiat currency to the digital asset seller. Inembodiments, an exchange may hold, e.g., as custodian, fiat in bankaccounts and digital assets in digital wallets at associated digitalasset addresses. In embodiments, instead of using bank accounts, otherstable investment instruments such as money market mutual funds,treasury bills, certificates of deposits, low risk bonds, to name a few,may be used.

FIG. 4A is another schematic diagram illustrating entities associatedwith a digital asset exchange in an exemplary embodiment of the presentinvention. Each entity may operate one or more computer systems.Computer systems may be connected directly or indirectly, such asthrough a data network. Entities associated with a digital assetexchange can include the exchange, an exchange computer system 3230,customer digital asset wallets at associated digital asset addresses3222 (e.g., bitcoin wallets, ether wallets, to name a few), customerbanks 3224 having customer fiat bank accounts 3226, a digital assetnetwork ledger 3228 (e.g., the Bitcoin blockchain, the Ethereumblockchain, to name a few), a digital asset network (e.g., the BitcoinNetwork, the Ethereum Network, to name a few), one or more exchangecustomers using one or more customer user device 3232, an exchangedigital asset electronic ledger 3234, one or more exchange digital assetvaults 3238, an exchange fiat electronic ledger 3236, and one or moreexchange partner banks 3242, which can have exchange pooled customerfiat accounts 3244. The exchange digital asset vaults 3238 can store aplurality of digital asset wallets, which may be pooled exchangecustomer wallets 3240 with associated digital asset addresses. Inembodiments, the exchange may have a single partner bank 3242 with apooled exchange customer fiat account 3244. Such an account may beassociated with insurance protection. In embodiments, the exchange mayhave a SVCoin system 3246. Such a system may allow users to purchaseSVCoin tokens using fiat currency and/or digital assets and/or to redeemdigital assets in the form of SVCoin tokens, and/or to redeem SVCointokens for fiat currency. SVCoin system 3246 may also be used togenerate new SVCoin tokens, and cancel redeem SVCoin tokens. SVCoinsystem 3246 is operatively connected to an SVCoin database thatmaintains a log of SVCoin tokens. In embodiments, the SVCoin databasemay be maintained as part of the digital asset network (e.g., theBitcoin Network, the Ethereum Network, to name a few).

The exchange may employ an electronic ledger system to track customerdigital assets and/or customer fiat holdings. Such a system may allowrapid electronic transactions among exchange customers and/or betweenexchange customers and the exchange itself using its own digital assetand fiat holdings or those of its sponsor or owner. In embodiments, theelectronic ledger system may facilitate rapid computer-based automatedtrading, which may comprise use by one or more computer systems of atrading API provided by the exchange. The electronic ledger system mayalso be used in conjunction with cold storage digital asset securitysystems by the exchange. Fiat (e.g., USD) and digital assets (e.g.,bitcoin or ether) can be electronically credited and/or electronicallydebited from respective (e.g., fiat and digital asset) electronicledgers. Clearing of transactions may be recorded nearly instantaneouslyon the electronic ledgers. Deposits of fiat with the exchange andwithdrawals from the exchange may be recorded on the electronic fiatledger, while deposits and withdrawals of digital assets may be recordedon the electronic digital asset ledger. Electronic ledgers may bemaintained using one or more computers operated by the exchange, itssponsor and/or agent, and stored on non-transitory computer-readablememory operatively connected to such one or more computers. Inembodiments, electronic ledgers can be in the form of a database.

A digital asset exchange computer system can include one or moresoftware modules programmed with computer-readable electronicinstructions to perform one or more operations associated with theexchange. Each module can be stored on non-transitory computer-readablememory operatively connected to such one or more computers. An exchangemay have a user on-boarding module to register users with the exchangeand/or create accounts for new and/or existing exchange users. Theexchange may employ systems and methods to ensure that the identity ofexchange customers is verified and/or the destination of fiat currencyand/or digital assets is known.

FIGS. 5A-B are schematic diagrams of exemplary exchange computer systemsin accordance with exemplary embodiments of the present invention. FIG.5A shows hardware, data, and software modules, which may run on one ormore computers. FIG. 5B shows an exemplary distributed architecture forthe exchange computer system.

As shown in FIG. 5A, an exchange computer system 3230 can include one ormore processors 5102, a communication portal 5104 (e.g., for sendingand/or receiving data), a display device 5106, and/or an input device5108. The exchange computer system 3230 can also include non-transitorycomputer-readable memory with one or more database and data storedthereon. Data can include user identification data 5110 (e.g. know yourcustomer data obtained during the user onboarding process), user accountauthentication data 5112 (e.g., login credentials, multi-factorauthentication data, and/or anti-money laundering verifications),account activities logs 5114, electronic ledger data 5116, fiat accountbalance data 5118, digital wallet balance data 5120, and/or SVCoin data5136, to name a few. One or more software modules may be stored in thememory and running or configured to run on the one or more processors.Such modules can include a web server module 5122, authenticator module5124, risk management module 5126, matching engine module 5128,electronic ledger module 5130, digital wallet module 5132, fiat accountmodule 5134 and/or SVCoin module 5138, to name a few. The processesperformed by such modules, the data produced thereby and/or the dataaccessed thereby are described herein.

A matching engine 5128 may apply a continuous order book price timepriority matching algorithm. In embodiments, the matching engine mayapply option points at low and/or high frequencies. In embodiments,other matching engines may be included, such as a block trade matchingengine (not shown), an auction matching engine (not shown), to name afew.

As shown in FIG. 5B an exchange computer system can include a web server5152, an authenticator computer system 5154, a matching engine computersystem 5156, an electronic ledger computer system 5158, a riskmanagement computer system 5160, a digital wallet computer system 5162,and/or a fiat account computer system 5164. The exchange computer system3230 may communicate with one or more external computer systems, such asbank computer systems, index computer systems, user computer system(e.g., institutional or individual users), and/or user electronicdevices, to name a few. Each computer system may comprise one or morecomputers and/or one or more processors, a communication portal, displaydevices, and/or input devices, to name a few.

A web server 5152 may provide display data to one or more user device102, e.g., user device 102-1. Display data may comprise website content(e.g., HTML, JavaScript, and/or other data from which a user device cangenerate and/or render one or more webpages) and/or application content,such as mobile application content, to be used in generating orproviding display content for one or more software application. Inembodiments, the web server 5152 may authenticate a user account byverifying a received username and password combination. In embodiments,other authentication processes may also be used.

An authenticator computer system 5154 may perform authentication of userlogin credentials, multi-factor authentication, and/or compare usersagainst databases, such as government databases, for compliance withanti-money laundering laws and/or regulations, to name a few.

A matching engine computer system 5156 may match buy (purchase) orderswith sell orders, receive orders, and/or update an electronic orderbook, to name a few.

An electronic ledger computer system 5158 may track and/or store accountbalances, update account balances, compute account balances, reportaccount balances, and/or place holds on account funds while transactionsare in progress (e.g., set an account hold indicator), to name a few.

A risk management computer system 5160 may perform processes to detectfraudulent transactions and/or security breaches, to name a few. Such asub-system may monitor access data describing access of the exchange(e.g., IP addresses, accounts, times of access, to name a few), monitortrading data, analyze trading data, determine patterns, determineanomalies, and/or determine violations of pre-programmed security rules,to name a few.

A digital wallet computer system 5162 may generate digital wallets withassociated digital asset addresses, generate instructions for digitalwallet key storage and/or retrieval, allocate digital assets amongdigital wallets, track digital assets, store digital asset, and/ortransfer digital assets, to name a few.

The digital wallets may include both hot wallets and cold wallets. Inembodiments, sufficient digital assets will be stored in one or more hotwallets to allow for liquidity. The amount of digital assets stored inthe one or more hot wallets may be determined based on historicalaverages of trading on the exchange. In embodiments, remaining digitalassets will preferably be held in cold wallets. A more detaileddiscussion of hot wallets and cold wallets is presented in U.S. Pat. No.9,892,460 issued Feb. 13, 2018 entitled SYSTEMS, METHODS, AND PROGRAMPRODUCTS FOR OPERATING EXCHANGE TRADED PRODUCTS HOLDING DIGITALMATH-BASED ASSETS, the entire content of which is incorporated herein.

A fiat account computer system 5164 may manage omnibus or pooledaccounts for holding customer funds. The fiat account computer systemmay process receipts of funds, e.g., from a bank, via a wire transfer,via a credit card or ACH transfer, and/or via check, to name a few.Accordingly, the fiat account computer system may communicate with oneor more external systems, such as a bank computer system. Inembodiments, the fiat account computer system may process withdrawals.In embodiments, the omnibus or pooled accounts for holding fiat aremaintained in a bank or other institution such that these accounts areeligible for insurance under the Federal Deposit Insurance Corporation(FDIC). In order to qualify for FDIC insurance, an account musttypically be associated with specific user identification information,e.g., a user name, address and social security number, by way ofexample, to name a few. Accordingly, in embodiments, fiat accounts maybe associated with individuals who are positively identified. In suchembodiments, SVCoin holders may be required to provide theidentification information discussed above prior to purchasing SVCoins.Further, the SVCoin issuer will maintain a database including thisinformation for each SVCoin holder. In embodiments, the fiat may beinvested in federally insured interest bearing bank accounts, CD's,money market mutual funds, Repos or other financial instruments whichoffer a return and provide sufficient stability, to name a few.

A SVCoin computer system 5166 may manage purchases of SVCoin tokensusing fiat currency and/or digital assets and/or redemption of digitalassets in the form of SVCoin tokens, and/or redemption of SVCoin tokensfor fiat currency. SVCoin computer system 5166 may also generate newSVCoin tokens, and cancel redeem SVCoin tokens. SVCoin computer system5166 is operatively connected to an SVCoin database 5136 that maintainsa log of SVCoin tokens. In embodiments, the SVCoin database 5136 ismaintained by the use of smart contract code associated with a ContractAddress on the digital asset blockchain though the digital assetnetwork.

Referring to the fiat account funding process shown in FIG. 6, in a stepS4720 the exchange computer system may receive fiat funding accountinformation. Such information can include a bank account number (e.g., arouting number), a bank name, an account type, and/or an accountholder's name, to name a few. In a step S4722, the exchange computersystem may perform one or more validation transactions using the fiatfunding account. Such transactions may comprise small deposits into thefiat funding account. In a step S4724, the exchange computer system mayreceive validation transaction information, which may include atransaction amount, date, and/or time. In a step S4726, the exchangecomputer system may electronically authorize use of the fiat fundingaccount and/or request a funding transfer. Accordingly, the exchangecomputer system may provide an electronic notification, e.g., via email,via a website, and/or via a mobile phone application (e.g., via a pushnotification), to name a few, that the fiat funding account isauthorized for use with the exchange. A customer may electronicallyinitiate a transaction, e.g., through an exchange-provided userinterface or user electronic device operatively connected to theexchange or an application programming interface (API), to name a few,to transfer funds to the exchange. In a step S4728, the exchangecomputer system may receive an electronic notification indicating thatfunds were received, e.g., in an exchange bank account at a partnerbank, from the customer fiat funding account. In a step S4730, theexchange computer system can update an exchange customer account withthe received funds. Updating an exchange customer account can compriseelectronically updating a fiat electronic ledger stored one or morecomputer readable media operatively connected to the exchange computersystem to reflect the received funds and/or updating a display of theamount of funds in the account or a data ledger on a user computerdevice or on a printed and/or digitally transmitted receipt provided tothe user and/or a user device.

Referring to the digital asset account funding process shown in FIG. 6,in a step S4734, the exchange computer system can receive an initialtransfer of digital assets. In a step S4736, the exchange computersystem can receive a confirmation of clearance of the digital assettransfer. In a step S4738, the exchange computer system can update anexchange customer account with the received digital assets. Updating anexchange customer account can include making an electronic entry in anexchange digital asset electronic ledger and/or providing a notificationthat the digital assets are received.

FIG. 7A is an exemplary schematic diagram of an exchange, and FIG. 7B isa corresponding flow chart of a process for digital asset exchangecustomer account fiat funding via an exchange-initiated request, such asACH in accordance with exemplary embodiments of the present invention.An exchange computer system 4810 can interface with a customer digitalasset wallet 4802, a bank 4804 with a customer fiat bank account 4806,an exchange partner bank 4822 with an exchange pooled customer fiataccount 4824, a network digital asset ledger 4808, and/or a customer'suser device 4812, to name a few. In addition to the exchange computersystem 4810, the exchange can include an exchange digital assetelectronic ledger 4814, an exchange fiat electronic ledger 4816, and anexchange digital asset vault 4818 with exchange pooled customer digitalasset wallets 4820 with associated digital asset addresses. Any of theseentities or components may communicate directly and/or indirectly, e.g.,through a data network, such as the Internet. In embodiments, encryptionand/or other security protocols may be used. These entities andcomponents are further described with respect to FIG. 4A.

Referring to FIG. 7B, in a step S4802 the exchange computer system canreceive, e.g., from a user device, user access credentials. In a stepS4804, the exchange computer system can authenticate the user, such asby verifying the received access credentials. In a step S4806, theexchange computer system may provide to a customer user device a fiatfunding interface. In a step S4808, the exchange computer system mayreceive from the user device user selections for a funding source and/orfunding method. The funding source may identify a bank account or otherfiat account. The funding method may identify ACH transfer or wiretransfer, to name a few. In a step S4810, the exchange computer systemcan receive from the user device a funding amount value to transfer toan exchange account associated with the user. In embodiments, S4808 andS4810 may be a single step. Accordingly, the exchange computer systemmay receive from a user electronic device a user electronic requestcomprising a funding amount and a funding method. In embodiments, thefunding method may be an ACH transfer and the request further identifiesa verified user bank account.

In a step S4812, the exchange computer system can transmit a fundtransfer request to a bank where the customer has a fiat bank account.Accordingly, the exchange computer system may transmit to an exchangepartner bank an electronic funding request comprising the funding amountand the user bank account identifier.

In a step S4814, the exchange computer system can update an exchangefiat electronic ledger with the funding transaction information. In astep S4816, the exchange computer system can receive an electronicindication that the funding amount was transferred from the customer'sfiat bank account to an exchange fiat account, e.g., at a partner bank.In a step S4818, the exchange computer system can monitor the exchangefiat account to determine the availability of funds in an exchangeaccount associated with the user. In embodiments, the exchange computersystem may generate and/or provide an electronic notification to one ormore user devices associated with a user account that funds areavailable for use on the exchange. In embodiments, the notification mayindicate a current balance of a user account (e.g., in fiat currencyand/or digital asset quantities).

FIG. 7C is an exemplary schematic diagram of an exchange, and FIG. 7D isa corresponding flow chart of a process for digital asset exchangecustomer account fiat funding via a customer-initiated request, such asa wire transfer, in accordance with exemplary embodiments of the presentinvention. The components and entities associated with an exchange thatare shown in FIG. 7C are described with respect to FIG. 4A.

FIG. 7D is a flow chart showing an exemplary process for digital assetexchange customer account fiat funding. In a step S4852, an exchangecomputer system can receive user access credentials. In a step S4854,the exchange computer system can authenticate the user by verifying thereceived access credentials. Verifying the access credentials cancomprise comparing the credentials to a secure credentials database. Ina step S4856, the exchange computer system can provide to a customeruser device a fiat funding interface. In a step S4858, the exchangecomputer system can receive from the customer user device, userselections for a funding source and/or funding method. The fundingmethod may be a customer-initiated method, such as a wire transfer. In astep S4860, the exchange computer system can receive a funding amountvalue to transfer to an exchange account associated with the user. In astep S4862, the exchange computer system can provide to the customeruser device fund transfer instruction, e.g., wire instructions. In astep S4864, the exchange computer system may receive an electronicindication of a customer-initiated fund transfer from a customer fiatbank account a customer bank to an exchange fiat account at an exchangepartner bank according to the fund transfer instructions. Inembodiments, step S4864 may be skipped. In a step S4866, the exchangecomputer system may receive an indication that the funding amount wastransferred from the customer's fiat bank account to the exchange fiataccount. In a step S4868, the exchange computer system can update anexchange fiat electronic ledger with the funding transactioninformation, which may include an amount value, customer account ID,transaction date and/or time, to name a few. In a step S4870, theexchange computer system can monitor the exchange fiat account todetermine the availability of funds in an exchange account associatedwith the user. In a step S4872, the exchange computer system can providean electronic notification to one or more customer user devices thatfunds are available for use on the exchange.

FIG. 7E is a flow chart showing another exemplary process for digitalasset exchange customer account fiat funding. In a step S4852′, anexchange computer system can receive user access credentials. In a stepS4854′, the exchange computer system can authenticate the user byverifying the received access credentials. Verifying the accesscredentials can comprise comparing the credentials to a securecredentials database. In a step S4856′, the exchange computer system canprovide to a customer user device a fiat funding interface. In a stepS4857, the exchange computer system can receive a user electronicrequest comprising a funding amount and a funding method (e.g., a wiretransfer). In a step S4859, the exchange computer system can provide tothe customer user device, an electronic message and/or display datacomprising wire transfer instructions. In a step S4861, the exchangecomputer system can set a pending transfer indicator and/or initiate afunds receipt monitoring process. In a step S4863, the exchange computersystem can receive an electronic indication that funds were received viawire transfer at an exchange fiat account at an exchange partner bank.In a step S4865, the exchange computer system can verify that thereceived funds were transferred from the authorized customer's fiat bankaccount to the exchange fiat account. In a step S4868′, the exchangecomputer system can update an exchange fiat electronic ledger with thefunding transaction information, which may include an amount value,customer account ID, transaction date and/or time, to name a few. In astep S4870, the exchange computer system can monitor the exchange fiataccount to determine the availability of funds in an exchange accountassociated with the user. In a step S4872′, the exchange computer systemcan provide an electronic notification to one or more customer userdevices that funds are available for use on the exchange.

FIG. 8A is an exemplary schematic diagram of an exchange, and FIG. 8B isa corresponding flow chart of a process for digital asset exchangeaccount digital asset withdrawal in accordance with exemplaryembodiments of the present invention. The components and entitiesassociated with an exchange that are shown in FIG. 8A are describedherein with respect to FIG. 4A.

Referring to FIG. 8B, in a step S4902, an exchange computer system canreceive user access credentials. User access credentials can include anyof a username, password, fingerprints, access card scan (e.g., swipe ofa card associated with the exchange and having a magnetic strip), and/ora pin (e.g., a number provided via SMS, other text message service, oremail for multi-factor authentication), to name a few. In a step S4904,the exchange computer system can authenticate the user based upon thereceived user access credentials. In a step S4906, the exchange computersystem may provide to a customer user device a withdrawal interface. Ina step S4908, the exchange computer system may receive from the customeruser device user inputs comprising at least a destination digital assetaddress, typically associated with a destination digital wallet and arequested digital asset withdrawal amount value. In a step S4910, theexchange computer system may verify that a digital asset accountassociated with the customer contains sufficient digital assets to coverthe requested withdrawal amount. In embodiments, such verification cancomprise reading a digital asset electronic ledger and/or determining acustomer digital asset balance, e.g., based on summing transactionsrecorded on a digital asset electronic ledger. In a step S4912, theexchange computer system may update an exchange digital asset electronicledger to reflect the pending withdrawal. In embodiments, recording anentry in the electronic ledger prior to the withdrawal may be performedto prevent double spending. In other embodiments, such a step may beskipped. In a step S4914, the exchange computer system may execute thewithdrawal, e.g., by broadcasting the withdrawal to a digital assetnetwork electronic ledger, e.g., the Bitcoin Blockchain, the EthereumBlockchain, to name a few. In a step S4916, the destination wallet mayreceive an electronic notification of the receipt of digital assets fromthe exchange. In a step S4918, the exchange computer system may monitorthe network digital asset ledger to determine whether and/or when thewithdrawal transaction is confirmed. In a step S4920, the exchangecomputer system may update the digital asset electronic ledger, e.g., bydebiting the withdrawal amount from the customer's exchange account, toreflect confirmation of the withdrawal transaction. In a step S4922, theexchange computer system may provide to one or more customer userdevices an electronic notification of the withdrawal. Such anotification can include at least the customer's new digital assetbalance.

A digital asset exchange can include additional systems, which mayinclude software modules, for performing various functions of theexchange. For example, an exchange can include an account managementsystem, which may comprise a user account registration system for newusers and/or an existing user account management system. The exchangecan include a trading system, which may comprise an interactive tradinginterface system, an automated trading interface system, a tradeconfirmation notification system, and/or a trade transaction feeprocessing system. A fund transfer system can include a fiat accountfunding and redemption system, a digital asset accounting funding andredemption system, and an account funding and redemption fee processingsystem. An exchange can also include a trade settlement system. Acustomer service system can include a trade dispute resolution interfacesystem and a customer account management assistance system. A customerreporting system can include a gain an loss reporting system and atransaction history system. A fraud analysis system can monitortransactions to detect fraudulent and/or unauthorized transactions. Theexchange can also include a SVCoin system, which may comprise a purchasesystem, redemption system, and a dividend payment system. In a preferredembodiment, a SVCoin system is included to allow users to purchase andredeem stable value coins using fiat currency and/or other digitalassets.

Exchange Digital Asset Storage Structure

Deposited customer fiat may be held in a pooled fiat account maintainedin a partner bank. Meanwhile, digital assets held by the exchange may bemaintained in pooled digital addresses associated with pooled digitalwallets. The exchange may store digital assets using any of the securityand/or storage systems and methods discussed herein. The exchange canemploy any combination of varying levels of secure storage for itswallets. For example, portions of digital assets held by the exchangemay be maintained in cold storage with neither the wallet's private norpublic keys ever having been exposed to a digital asset network or otherexternal network, such as the Internet. Other digital assets may bestored in air-gapped hot wallets, which may be wallets generated offlinewith transactions generated offline, e.g., on an isolated computer, andtransferred to a networked computer via a temporary physical connectionor manual transfer. Other digital assets may be maintained in hotwallets, e.g., to satisfy withdrawals from the exchange. The exchangemay determine the amount of assets to hold in hot wallets, which may bebased on historical exchange activity and/or anticipated need. A hotwallet liquidity module may analyze and predict the amount of assets perwallet and/or during a time period required to meet anticipated need andmay also initiate transfers of assets to or from hot wallets to maintaindesired levels. For example, a hot wallet liquidity module coulddetermine that it is desirable to maintain digital assets in certaindefined amounts (e.g., 0.5 bitcoin), and/or certain defined fiat amounts(e.g., $100 worth of bitcoin) and/or of certain defined quantitiessufficient to cover transactions anticipated during a defined period(e.g., the day's transaction). In embodiments, initiating an electronictransfer may comprise electronically generating and providing anelectronic notification to devices associated with one or more exchangeadministrators of a need to transfer assets and/or an amount of assetsto transfer. The exchange may designate one or more wallets forreceiving incoming digital assets only. For example, the exchange mayemploy a single digital wallet for each receipt of digital assets, e.g.,from exchange users. The receiving wallet may be destroyed after thereceived assets are transferred to one or more other wallets.

The exchange may employ any of a number of different exchange digitalwallet systems. As discussed herein, the exchange may operate a pooledor omnibus digital wallet system, e.g., as part of a centralizedexchange system. The pooled system may use an electronic ledger to trackdigital asset ownership for each exchange customer. Customers maytransfer digital assets from their own digital wallets to an exchangeaddress in order to fund their digital asset account on the exchange.The ledger can track (e.g., record) such funding events, as well aswithdrawal events. Transfers of digital assets among customers can alsobe accounted for using the ledger. With a pooled wallet system, internaltransactions on the exchange (e.g., transactions that do not entailtransferring funds to or from the exchange or exchange wallets butrather transactions between exchange wallets) can be settled withoutdelay, since the transfer can be logged through electronic ledgerupdates and does not have to otherwise be processed by a digital assetnetwork.

In another embodiment, the exchange digital wallet system may compriseexchange operated wallets for each exchange customer. These exchangeoperated wallets may be maintained in trust by the exchange for eachcustomer as associated digital asset addresses. Transactions may beprocessed by the digital asset network, e.g., the Bitcoin network, theEthereum network, to name a few. The keys to each customer wallet may beheld by the customer and/or by the exchange. Transactions may be settledvia the digital asset network in real-time (with any correspondingconfirmation period) as they occur, or transactions may be settled in abatch, which may entail broadcasting a plurality of transactions to thenetwork at a particular time or periodically throughout a day.

In another embodiment of an exchange digital wallet system, the exchangecustomers may own and/or manage their own wallets, e.g., as part of adecentralized exchange system. The exchange would not hold any customerdigital assets, and customers would hold the private keys to theirwallets with associated digital asset addresses. The exchange may matchcustomers, as described herein, so that a digital asset seller cantransfer digital assets from the seller's digital wallet to a digitalwallet corresponding to a digital asset buyer.

In embodiments, the digital wallet may be a custodial digital wallet.The custodial digital wallet may be segregated, that is, unique to aparticular customer or commingled, including digital assets of multiplecustomers. In such an embodiment, the custodian holds digital assets inthe custodial wallet for the benefit of its customers. The custodianwould hold the private key or private keys/key segments to eachcustodial wallet whether it be segregated or commingled. Transactionsmay be made between different custodial wallets or between custodialwallets and exchange customer wallets in the manner described above.

Centralized Digital Asset Exchange

In embodiments, the exchange may hold customer fiat currency and/ordigital assets in centralized, pooled accounts or wallets. The exchangemay maintain an electronic ledger to record transactions among users ofthe exchange. Separate electronic fiat account ledgers and electronicdigital asset ledgers may be maintained. Maintaining a ledger mayinvolve electronically updating the ledger to reflect pendingtransactions and/or completed transactions, which may involve debitingassets from a user's account and/or crediting assets to a user'saccount. Broadcast to a digital asset network and confirmation from adigital asset network may not be performed for transactions within theexchange, e.g., transactions between a digital asset seller sellingdigital assets that are stored by the exchange and a buyer paying withfiat currency that is held in an exchange bank account, such as a pooledaccount.

In embodiments, for both a decentralized and a centralized exchange theexchange may provide the ability for customers to purchase digitalassets from the exchange and/or sell digital assets to the exchange suchthat the exchange operator or owner is the counterparty to thetransaction. Transaction amount limits may be placed on suchtransactions and/or additional fees may be charged. In addition, inembodiments, the exchange may provide a dashboard interface for users(such as registered users) to purchase SVCoins using fiat currencyand/or digital assets and/or to redeem digital assets in the form ofSVCoins. In embodiments, the dashboard interface for the exchange mayalso allow users to redeem SVCoins for fiat currency. Since SVCoins arepegged to a fixed notional value of fiat currency, when SVCoins arepurchased an equal amount of fiat will be set aside by the exchange as areserve for when the SVCoins are redeemed. Similarly, when SVCoins areredeemed, payment for such redemption shall come from reserves set asidefor such redemption.

Exchange Operations Systems

In embodiments, a digital asset exchange may require users to opendesignated accounts associated with the user in order to participate inthe exchange. Each user may have a digital math-based asset account torecord and maintain such user's digital math-based assets and a fiataccount to record and maintain such user's fiat assets. In embodiments,the fiat assets recorded in the fiat account may be U.S. Dollars (“USD”)held in one or more omnibus bank accounts with one or more FDIC-insureddepository institutions or banks. In embodiments, a digital math-basedasset computer system of a digital asset exchange may record in anelectronic ledger information associated with a user account, such asdigital math-based asset purchase orders, digital math-based asset sellorders, digital math-based asset purchase offers, digital math-basedasset sell offers. In embodiments, digital math-based asset purchaseoffers and digital math-based asset sell offers may be converted intodigital math-based asset purchase orders and digital math-based assetsell orders, respectively, according to a user's instructions, ifcertain user-specified factors are met (e.g., digital math-based assetsare within a given price, quantity, period of time, to name a few). Inembodiments, when the digital math-based asset computer system matchesan electronic digital math-based asset purchase order with an electronicdigital math-based asset sell order, the digital math-based assetcomputer system may record the trade in an electronic ledger,effectively transferring ownership of the seller's traded digitalmath-based assets to the buyer, and ownership of the related purchaseprice in fiat currency from the buyer to the seller. In embodiments, thechanges in a user's ownership of digital math-based assets and fiatcurrency recorded in the electronic ledger are reflected in a user'sdigital math-based asset account and fiat account.

In embodiments, a digital asset exchange may accept payment methods(e.g., credit card transactions; Automated Clearing House (ACH) debits,wire transfers, digital asset transactions, to name a few) for purchasesof digital assets.

In embodiments, a digital asset exchange may hold digital math-basedassets and/or fiat currency in trust for users. Fiat currency may bemaintained in accounts with a state or federally chartered bank and maybe eligible for FDIC insurance, subject to compliance with applicablefederal regulation. In embodiments, a digital asset exchange may alsooperate a digital math-based asset storage system, in which users maydeposit digital math-based assets. In embodiments, fiat currency may betransmitted to a digital asset exchange's omnibus account. Inembodiments, the exchange may transmit fiat currency back to a user uponreceiving a request from a user.

In embodiments, a digital asset exchange may comply with relevant lawsand regulations whereby the exchange may operate in a highly regulatedbanking environment and permit necessary supervision by relevant legalauthorities. In embodiments, a digital asset exchange may comply withrules and regulations promulgated by a self-regulatory organization.

In embodiments, when a user commences an electronic digital math-basedasset purchase order to acquire digital math-based assets, the user mayeither have fiat currency in an associated user account or the buyer maysend fiat currency to the digital asset exchange's omnibus account atthe applicable bank. In embodiments, when a seller commences anelectronic digital math-based asset sell order to sell digitalmath-based assets, the seller may either have digital math-based assetsin an associated user account or may send digital math-based assets to adigital math-based asset account. In embodiments, the seller may senddigital math-based assets to one or more of digital wallets held by theexchange. In embodiments, exchange transactions may only be completedafter the digital math-based asset computer system verifies that thedigital math-based asset accounts and fiat accounts associated with theusers involved in the transaction at least equal the quantities requiredby the transaction.

In embodiments, the exchange may permit trading twenty-four hours a day,seven days a week. In embodiments, the exchange may shut down forscheduled and/or unscheduled maintenance periods. In embodiments, theexchange may prohibit users from transferring fiat currency outside ofnormal business hours, in order to comply with applicable laws andregulations. In embodiments, the exchange may allow users to deposit andwithdraw digital math-based assets outside of normal business hours. Inembodiments, the exchange may permit users to sell digital math-basedassets for fiat currency or buy digital math-based assets with fiatcurrency if the user holds sufficient fiat currency in its associatedaccount prior to initiating the transaction.

Exchange-Based Stable Value Coin to Fiat Portal

In embodiments, a digital asset exchange (such as a regulated exchange)can be used to exchange SVCoin for fiat and fiat for SVCoin. SinceSVCoin is a stable value token, each token will be pegged to a stablevalue of fiat (e.g., 1 SVCoin=1 USD or 1 SVCoin=1 EUR, to name a few).In embodiments, when fiat is provided to a digital asset exchange topurchase SVCoin, a sufficient amount of fiat to cover the notional valueof the SVCoin will be set aside and held until the SVCoin is redeemed.Similarly, when SVCoin is redeemed the corresponding amount of fiatassociated with the notional value of the SVCoin will be taken from suchreserves to cover the redemption. In embodiments, each time SVCoins arepurchased, redeemed and/or traded, transaction fees may be charged bythe SVCoin issuer, and/or others involved in the transaction, such asminers on the digital asset network. Such transaction fees may becharged in fiat, SVCoin and/or other digital assets (e.g, Gas, bitcoin,ether, to name a few).

In embodiments, when a user (such as a registered user of a regulateddigital asset exchange) commences a purchase order to acquire SVCoin forfiat, the user may have fiat currency in an associated user account.Alternatively, the user may send fiat currency to the exchange'saccount, such as an omnibus account, at the applicable bank. Inembodiments, when a seller sells SVCoin, the seller may have the SVCoinin an associated user account or may send SVCoin to a digital assetaccount. Specifically, the seller may send SVCoin to one or more ofdigital asset addressed, typically associated with digital wallets heldby the exchange. In embodiments, exchange transactions may only becompleted after the verification that the digital asset accounts andfiat accounts associated with the users involved in the transaction atleast equal the quantities of each required by the transaction.

In embodiments, registered users of a digital asset exchange system,such as Gemini, may purchase and/or redeem SVCoins for fiat and/or otherdigital assets though one or more digital asset dashboard interfaces. Inembodiments, the one or more digital asset dashboard interfaces mayinclude: (i) a dashboard fiat interface which allows registered users todeposit and/or withdrawal fiat with the digital asset exchange, (ii) adashboard digital asset interface which allows registered users todeposit and/or withdrawal digital assets with the digital asset exchangesystem, (iii) a dashboard SVCoin interface which allows registered usersto purchase and/or redeem SVCoins with the digital asset exchangesystem; and (iv) a dashboard Security Token interface which allowSecurity Token issuers to provide instructions to transfer SVCoins toSecurity Token holders. Each of these dashboard interfaces will now bedescribed in turn.

FIGS. 11A1-4 illustrates an exemplary embodiment of a dashboard fiatinterface which allows registered users to deposit and/or withdraw fiatwith the digital asset exchange.

FIG. 11A1 illustrates an exemplary embodiment of the dashboard fiatinterface as used for deposit of fiat. As illustrated, the user has theoption to make a transfer from a bank to the exchange by indicating anamount of fiat 1102 (e.g., US dollars) to be transferred from a fundingsource 1100 (e.g., a bank account).

FIG. 11A2 illustrates an exemplary embodiment of the dashboard fiatinterface providing an option of a wire transfer. As in FIG. 11A1, theuser indicates an amount of fiat 1102 to be transferred from a fundingsource 1100, such as a bank, to be wired to the exchange.

FIG. 11A3 illustrates the dashboard fiat interface as used to withdrawfiat from the exchange and deposit it into a destination (e.g., a bank).In this case, the user provides a withdrawal amount of fiat 1104 and adestination 1106, such as a bank account, for the specific fiat.

Similarly, FIG. 11A4 illustrates the dashboard fiat interface as used towithdraw fiat via a wire transfer where the user enters the withdrawalamount of fiat 1104 and a destination 1106, such as a bank account.

FIGS. 11B1-4 illustrates an exemplary embodiment of a dashboard digitalasset interface which allows registered users to deposit and/orwithdrawal digital assets with the digital asset exchange system.

FIG. 11B1 illustrates an exemplary embodiment of the dashboard fiatinterface as used for deposit of digital assets, specifically bitcoin inthis nonlimiting example. As illustrated, the user enters the currentaddress 1112 of the digital asset (e.g., bitcoin, ether, etc).

FIG. 11B2 illustrates another exemplary embodiment of the dashboard fiatinterface as used for deposit of digital assets, specifically ether thisnonlimiting example. As illustrated, the user enters the current address1112 of the digital asset (ether in this example.

FIG. 11B3 illustrates an exemplary embodiment of the dashboard fiatinterface as used for withdrawal of digital assets, specifically bitcoinin this nonlimiting example. As illustrated, the user enters thedestination address 1114 for the digital asset (bitcoin) as well asamount of digital assets 1116 to be withdrawn.

FIG. 11B4 illustrates an exemplary embodiment of the dashboard fiatinterface as used for withdrawal of digital assets, specifically etherthis example. As illustrated, the user enters the destination address1114 of the digital asset (ether) as well as amount of digital assets1116 to be withdrawn.

FIGS. 11C1-2 illustrates an exemplary embodiment of a dashboard SVCoininterface which allows registered users to purchase and/or redeemSVCoins with the digital asset exchange system.

FIG. 11C1 illustrates an exemplary embodiment of the dashboard fiatinterface as used to purchase SVCoins using fiat. As illustrated, theuser may enter an amount of fiat (U.S. dollars, in this example) 1122 tobe provided from a source 1124 (e.g., a bank account) to purchase theSVCoins.

FIG. 11C2 illustrates an exemplary embodiment of the dashboard fiatinterface as used to purchase SVCoins using digital assets (bitcoin inthis example). As illustrated, the user may enter the current address ofthe digital asset 1126.

In embodiments, a registered user may purchase SVCoins in exchange forfiat. Referring to FIG. 9A, in S9902, a registered user may log in tothe dashboard SVCoin interface, such as illustrated in FIGS. 11C1-2.

In S 9904, the user selects the purchase SVCoin option, and specifiesthe amount of SVCoins the user seeks to obtain. In embodiments, the usermay be requested to provide a digital asset address, typicallyassociated with a digital wallet, such as a digital asset addressassociated with a blockchain digital asset, like ether. In embodiments,the amount of SVCoins to be purchased may be specified by number ofSVCoins, or by an amount of fiat. Since the SVCoins are pegged to thefiat in a stable amount (e.g., 1 SVCoin=1 USD), the system canautomatically convert and display the requested amount of SVCoin intofiat, or requested amount of fiat into SVCoin.

In S9906, the digital asset exchange system will analyze and verify thatthe request can be properly processed. In step S9906-a, the digitalasset exchange system, as the SVCoin issuer, may verify that the userhas sufficient fiat currency maintained at the digital asset exchange tocover the transaction, including a sufficient amount of fiat to coverthe amount of SVCoin being acquired, as well as any transaction feesthat may be charged. If the user does not have sufficient fiat in thesystem, the transaction may be terminated for insufficient funds. Inembodiments, the user may be provided an opportunity to obtainsufficient funds, by, e.g., selling digital assets maintained by theuser on the digital asset exchange or by making a deposit of additionalfiat. In step S9906-b, the digital asset exchange system, may alsoverify that the digital asset address provided is a valid digital assetaddress.

In S9908, after the digital asset exchange system has confirmed that theuser has sufficient fiat to cover the transaction, the digital assetexchange system may initiate the process of generating the requestedSVCoin. In embodiments, where SVCoins were previously generated, thenS9908 may be replaced with an alternative process S9908′ as discussedbelow.

Returning to S9908, in S9908-a, the digital asset exchange system maydebit the designated fiat funds from a fiat ledger associated with theuser account, and credit a corresponding amount of fiat to the SVCoinfiat ledger to be held in trust by the Exchange.

In S9908-b, the digital asset exchange system shall generate therequested SVCoin tokens. As part of this step, or as an additional step,the digital asset exchange system will update the SVCoin ledger toreflect the creation of the newly generated SVCoins and to indicate thedigital asset address associated with these newly generated SVCoins.

In S9908-c, the digital asset exchange system shall publish to theblockchain network (e.g., the Ethereum Network) the transaction to berecorded by the blockchain network. In embodiments, a transaction feemay be required by, e.g., a miner, to process and add the requestedtransaction on the blockchain.

As noted, when a reserve of SVCoin had been previously created but notyet distributed by the digital asset exchange system, S9908′ may beimplemented instead of S9908. At step S9908-a′, digital asset exchangecomputer system may debit the designated fiat funds from a fiat ledgerassociated with the user account, and credit a corresponding amount offiat to the SVCoin fiat ledger to be held in trust by the Exchange.

In step S9908-b′, the digital asset exchange computer system maydetermines an appropriate amount of SVCoin from the reserve to satisfythe request.

In step S9908-c′, the digital asset exchange computer system updates theSVCoin ledger to change the address associated with the portion of thereserve determined in step S9908 b′ to the address associated with theuser.

In S9910, the digital asset exchange computer system may send a messageto the registered user, and/or the designated digital asset address toreflect that the transaction was successfully processed. In embodiments,such messages may include information including: (i) digital assetaddress; (ii) the amount of tokens generated; and/or (iii) the newbalances for the digital asset address.

In embodiments, a registered user may redeem SVCoins in exchange forfiat. Referring to FIG. 9B, in S9952, a registered user may log in tothe dashboard SVCoin interface, such as illustrated in FIGS. 11C1-2.

In S9954, the user selects the redeem SVCoin option, and specifies theamount of SVCoins the user seeks to redeem. In embodiments, the user maybe requested to provide a digital wallet address, such as a digitalwallet address associated with a blockchain digital asset, like ether.In embodiments, the amount of SVCoins may be specified by number ofSVCoins, or by an amount of fiat. Since the SVCoins are pegged to thefiat in a stable amount (e.g., 1 SVCoin=1 USD), the system canautomatically convert the requested amount of SVCoin to fiat, orrequested amount of fiat into SVCoin.

In S9956, the digital asset exchange system will analyze and verify thatthe request can be properly processed. In step S9956-a, the digitalasset exchange system, as the SVCoin issuer, may verify that the userhas sufficient SVCoin to cover the transaction, as well as anytransaction fees that may be charged. In embodiments, the digital assetexchange system may perform verification of the SVCoin balance bychecking the token balance of the digital asset address against theSVCoin Token ledger as maintained by the digital asset blockchain. Forexample, a balance for a token issued based on the Ethereum Network maybe check at www.etherscan.io. If the user does not have sufficientSVCoin and/or an insufficient amount for transaction fees and/orprovided an invalid digital asset address, to name a few, thetransaction may be terminated.

In embodiments, SVCoin transactions may be published and recorded in aSVCoin token side ledger that is separate from an underlying blockchain(e.g., the Ethereum Blockchain). Such a side ledger may be providedusing a sidechain, for example, a plasma chain, which is separate fromthe underlying digital asset blockchain that is maintained on thedistributed network. In embodiments, this sidechain is used to recordall transactions involving the SVCoin token and is maintained by thetoken issuer or another trusted entity on behalf of the token issuer.These transactions may then be subsequently published to the underlyingdigital asset blockchain periodically or aperiodically such that alltransactions are publicly viewable and confirmable. In embodiments, witha blockchain supporting shielded transactions, the transactions in theSVCoin token may potentially be shielded only viewable by authorizedtoken holders. In embodiments, transactions on the sidechain may beconsolidated prior to publication on the digital asset blockchain toincrease speed of processing and reduce transaction costs.

The use of a sidechain in conjunction with a blockchain can providecertain technical advantages not otherwise available by either alone.For example, since all transactions on the sidechain are inevitablypublished to the digital asset blockchain, these transaction recordsenjoy the same benefit of immutability provided to all othertransactions on the digital asset blockchain. However, use of asidechain reduces both transaction costs and transaction times overall.Recording the transactions on the sidechain first can be accomplishedmore rapidly than transactions that are published directly to thedigital asset blockchain, which must be confirmed prior to being addedto the digital asset blockchain. In embodiments, the sidechain maysimply be a database that records all transactions such that there is noneed for miners to verify each transaction, and thus, no need to payminers for this service. In this case, transaction costs are onlyincurred for the periodic or aperiodic publication of transfers from thesidechain to the underlying digital asset blockchain.

In embodiments, the database for the SVCoin tokens may be maintained asa separate side chain from the database for each Security token. Inembodiments, one or more security tokens may be maintained in the sameside chain as the SVCoin token, and/or by the same trusted entity systemas used to maintain the SVCoin token database.

In S9958, after the digital asset exchange system may confirm that theuser has sufficient SVCoin to cover the transaction, as well as anyother designated criteria, the digital asset exchange system mayinitiate the process of redeeming the designated SVCoin.

In S9958-a, the digital asset exchange system shall redeem thedesignated SVCoin tokens, including updating the SVCoin token ledgerdatabase to reflect the debiting and cancelling of the designated tokensand debiting the corresponding digital wallet address associated withsuch redeemed SVCoin tokens. In embodiments, this process may beperformed by generating a transaction on the digital asset exchangenetwork from a contract digital wallet address or other authorizeddigital wallet address under the relevant SVCoin smart contractprogramming, to be sent in S9958-c, discussed below.

In S9958-b, the digital asset exchange system shall credit thedesignated fiat funds to a fiat ledger associated with the user account,and debit a corresponding amount of fiat from the SVCoin fiat ledgerbeing held in trust by the exchange.

In S9958-c, the digital assert exchange system shall publish to theblockchain network (e.g., the Ethereum Network) the transaction to berecorded by the blockchain network. In embodiments, a transaction fee(such as Gas) may be required by, e.g., a miner, to process and add therequested transaction on the blockchain. In embodiments, the transactionfee may be specified as an amount and/or an amount limit to facilitatethe transaction being processed by a miner.

In S9960, the digital asset exchange computer system may send a messageto the registered user, and/or the designated digital asset addresses toreflect that the transaction was successfully processed. In embodiments,such messages may include information including: (i) digital assetaddress; (ii) the amount of tokens redeemed; and/or (iii) the newbalances for the digital asset address or digital wallet associatedtherewith.

Blockchain Based Dividend Using Stable Value Coin

FIG. 11D illustrates an exemplary embodiment of a dashboard SecurityToken interface which allow Security Token issuers to provideinstructions to transfer SVCoins to Security Token holders.

Referring to FIG. 12, an exemplary process flow reflecting an exemplaryembodiment is shown where a Security Token issuer initiates a transferof SVCoins to Security Token holders. It will be appreciated by thoseskilled in the art that the order of this process may be modifiedconsistent with embodiments of the present invention.

In Step S1202, the Security Token issuer (who will generally by aregistered user with the digital asset exchange) will log into thedigital asset exchange. In embodiments, the SVCoin issuer is any trustedentity, including a digital asset exchange, bank, trust or other trustedentity. In embodiments, the Security Token issuer will be an authorizeduser, or otherwise qualified with respect to the trusted entity. Inembodiments, the trusted entity may act as agent of the Security Tokenissuer to generate, distribute and maintain a ledger of SVCoins onbehalf of the Security Token issuer.

In Step S1204, the Security Token issuer system, or any trusted entitysystem acting as agent, will navigate to the dashboard Security Tokeninterface (see, e.g., FIG. 11D) to initiate a request for transfer ofSVCoins to Security Token holders. While for purposes of illustration,the request is made via the dashboard Security Token interface, those ofskill in the art will appreciate that the request may be made via APIcalls, submitted by electronic mail, and/or other electronicinteractions, consistent with embodiments of the invention. Inembodiments, the request shall identify: (i) the Security Token 1130;(ii) the total amount of SVCoins to be distributed 1132; (iii) theSecurity Token holder's digital asset addresses 1134; (iii) the amountof SVCoins to be distributed to each digital asset address 1136; and/or(iv) other information sufficient to calculate or otherwise determinethis information. In embodiments, this information may be provided byproviding the digital asset exchange, or other trusted entity systemacting on behalf of the SVCoin issuer, with the access to the SecurityToken database, which would include the list of all current SecurityToken holders and their respective digital asset address and SecurityToken balances. In embodiments, the Security Token database may includea list of all current Security Token holders and digital asset addressesassociated with each. In such embodiments, the Security Token issuer,may still need to provide the digital asset exchange system, or othertrusted entity system, with the amount of SVCoins to be distributed,either individually and/or in total and how to prorate the distributionamong Security Token holders.

In Step S1206, the digital asset exchange system, or other trustedentity system, may analyze and verify that the request can be properlyprocessed. In step S1206-a, the digital asset exchange system, as theSVCoin issuer or on behalf of the SVCoin issuer, may verify that theuser has sufficient fiat currency maintained at the digital assetexchange to cover the transaction, including a sufficient amount of fiatto cover the amount of SVCoin being acquired, as well as any transactionfees that may be charged. If the user does not have sufficient fiat inthe system, the transaction may be terminated for insufficient funds. Inembodiments, the user may be provided an opportunity to obtainsufficient funds, by, e.g., selling digital assets maintained by theuser on the digital asset exchange or by making a deposit of additionalfiat. In step S1206-b, the digital asset exchange system, may alsoverify that the digital asset addresses, provided are each a validdigital asset addresses. To the extent any digital asset addresses arenot verified, the transaction may be rejected, and/or the digital assetexchange system may enter into a reconciliation process with theSecurity Token issuer system or trusted entity system.

At step 1206-c, the digital asset exchange system, or other trustedentity system, may determine an amount of SVCoins to be distributed toeach of the digital addresses of the Security Token holders. Inembodiments, this determination may be made based on the total number ofSecurity Token holders and the total amount of SVCoins requested by theSecurity Token issuer. In embodiments, the Security Token issuer maydesignate a specific sum of SVCoins per Security token. In embodiments atotal amount of SVCoins to be purchased may be designated in the requestof the Security Token issue with directions to equally or proportionallydivide the total sum between the Security Token holders.

In S1208, after the digital asset exchange system, or other trustedentity system, has confirmed that the user has sufficient fiat to coverthe transaction, the digital asset exchange system may initiate theprocess of generating the requested SVCoin.

In S1208-a, the digital asset exchange system, or other trusted entitysystem, may debit the designated fiat funds from a fiat ledgerassociated with the Security Token issuer user account, and credit acorresponding amount of fiat to the SVCoin fiat ledger to be held intrust by the exchange. In embodiments, this fiat is held in a custodialaccount of the exchange or an agent of the exchange.

In S1208-b, the digital asset exchange system, or other trusted entitysystem, shall generate instructions to generate the requested SVCointokens, including instructions to update the SVCoin token ledgerdatabase to reflect the addition of the new tokens and the correspondingdigital asset addresses associated with such new SVCoin tokens.

In S1208-c, the digital asset exchange system, or other trusted entitysystem, shall publish to the blockchain network (e.g., the EthereumNetwork) the transaction with instructions to be recorded by theblockchain network. In embodiments, a transaction fee may be requiredby, e.g., a miner, to process and add the requested transaction on theblockchain.

In embodiments, where SVCoin tokens have already been created and aremaintained by the digital asset exchange system on reserve, S1208 may bereplaced with S1208′ as follows. In step 1208-a′, the digital assetexchange system, or other trusted entity system, may debit thedesignated fiat funds from a fiat ledger associated with the SecurityToken issuer user account, and credit a corresponding amount of fiat tothe SVCoin fiat ledger to be held in trust by the exchange, or otherwisereserved by the trusted entity.

At step S1208-b′, the digital asset exchange computer system, or othertrusted entity system may then determine a portion of the reserve fortransfer based on the requested amount of SVCoin identified by theSecurity Token issuer for transfer to the Security Token holder(s).

At step 1208-c′, the digital asset exchange computer system, or othertrusted entity system may update the SVCoin token ledger to change theaddress associated with the determined portion of the reserve SVCointokens to the address, or addresses, associated with the Security Tokenholder.

In S1210, the digital asset exchange computer system may send a messageto the Security Token issuer registered user, and/or each of thedesignated digital asset addresses to reflect that the transaction wassuccessfully processed. In embodiments, such messages may includeinformation including: (i) digital asset address; (ii) the amount oftokens generated/or determined for transfer; and/or (iii) the newbalances for the digital asset address or digital wallet associatedtherewith. In embodiments, the message may include additionalinformation related to the Security Token, including: (iv) the amount ofthe Security Token held; (v) the dividend issued; and/or (vi)instructions on how to redeem the SVCoin.

EXAMPLES

The following examples illustrate embodiments of the present invention.They are not intended to be limiting. It will be appreciated by those ofskill in the art that embodiments may be applied to other use cases notspecifically called out herein without departing from the presentinvention.

Example 1: Real Estate Investment Trust (REIT) Token

In embodiments, shares in a real estate investment trust (“REIT Trust”)may be issued using a digital asset, such as a token on the EtherNetwork (“REIT Token”). The REIT Trust may hold income generatingproperty such as real estate which is leased. As the income generatingproperty generates fiat profits which are intended to be distributed toshareholders, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into a SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the REIT Trust) to REIT Token holders at the respectiveREIT Token holder's digital asset addresses associated with the EtherWallet holding the REIT Token.

REIT Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 2: Energy Master Limited Partnership (Energy MLP) Tokens

In embodiments, shares in an Energy Master Limited Partnership (“EnergyMLP”) may be issued using a digital asset, such as a token on the EtherNetwork (“Energy MLP Token”). The Energy MLP may offer shares (otherwiseknown as “units”) in the form of a digital asset, such as Energy MLPTokens that are publicly traded and which generate dividends to theshareholders. As the dividends are distributed on a periodic basis inthe form of fiat currency, a corresponding amount of fiat is depositedwith a digital asset exchange, such as a regulated digital assetexchange like Gemini. The fiat is then converted into a SVCoin by theExchange. The SVCoin may then be distributed on a pro-rata basis (or asotherwise instructed by the Energy MLP) to Energy MLP Token holders atthe respective Energy MLP Token holder's digital asset addressesassociated with the Ether Wallet holding the Energy MLP Token.

Energy MLP Token holders may then use the SVCoin as a digital asset toconduct other transactions. Eventually, the SVCoin can be exchanged forfiat at the exchange based on the notional value (e.g., 1 SVCoin=1dollar).

Example 3: Equity Security Tokens

In embodiments, equity shares corresponding to a stock certificate in anentity may be issued using a digital asset, such as a token on the EtherNetwork (“Equity Token”). As dividends based on the Equity Token aregenerated for distribution to shareholders, a corresponding amount offiat is to be deposited with a digital asset exchange, such as aregulated digital asset exchange like Gemini. The fiat is then convertedinto a SVCoin by the Exchange. The SVCoin may then be distributed on apro-rata basis (or as otherwise instructed by the entity distributingthe shares) to Equity Token holders at the respective Equity Tokenholder's digital asset addresses associated with the Ether Walletholding the Equity Token.

Equity Token holders may then use the SVCoin as a digital asset toconduct other transactions. Eventually, the SVCoin can be exchanged forfiat at the exchange based on the notional value (e.g., 1 SVCoin=1dollar).

Example 4: Venture Capital (VC) Tokens

In embodiments, shares in a Venture Capital fund (“VC Fund”) may beissued using a digital asset, such as a token on the Ether Network (“VCToken”). As the VC Fund generates returns to be distributed to investorsin the VC Fund, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into a SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the VC Fund) to VC Token holders at the respective VCToken holder's digital asset addresses associated with the Ether Walletholding the VC Token.

VC Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 5: Private Equity (PE) Tokens

In embodiments, shares in a Private Equity fund (“PE Fund”) may beissued using a digital asset, such as a token on the Ether Network (“PEToken”). As the PE Fund generates returns to be distributed to investorsin the PE Fund, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the PE Fund) to PE Token holders at the respective PEToken holder's digital asset addresses associated with the Ether Walletholding the PE Token.

PE Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 6: Digital Certificate of Deposit (CD) Tokens

In embodiments, digital certificate of deposits (“Digital CD”) may beissued using a digital asset, such as a token on the Ether Network (“CDToken”). As interest amounts are generated based on the terms of thecertificate of deposits, a corresponding amount of fiat is to bedeposited with a digital asset exchange, such as a regulated digitalasset exchange like Gemini. The fiat is then converted into a SVCoin bythe Exchange. Upon maturity of the Digital CD (or before maturity), theSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the Digital CD issuer and/or less any premature withdrawalpenalty) to CD Token holders at the respective CD Token holder's digitalasset addresses associated with the Ether Wallet holding the CD Token.

CD Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 7: Digital Bond Tokens

In embodiments, digital bonds may be issued using a digital asset, suchas a token on the Ether Network (“Bond Token”). As interest amounts aregenerated based on the coupon rates of the digital bonds, acorresponding amount of fiat is to be deposited with a digital assetexchange, such as a regulated digital asset exchange like Gemini. Thefiat is then converted into SVCoin by the Exchange. The SVCoin may thenbe distributed on a pro-rata basis (or as otherwise instructed by thedigital bond issuer) to Bond Token holders at the respective Bond Tokenholder's digital asset addresses associated with the Ether Walletholding the Bond Token.

Bond Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 8: Peer-to-Peer Lending (P2P) Tokens

In embodiments, a peer-to-peer lending service (“P2P Service”) may issuea digital asset, such as a token on the Ether Network (“P2P LoanToken”). As lending amounts and interest payments are distributed,corresponding amounts of fiat is deposited with a digital assetexchange, such as a regulated digital asset exchange like Gemini. Thefiat is then converted into SVCoin by the Exchange. The SVCoin may thenbe distributed on a pro-rata basis (or as otherwise instructed by thelender/borrower) to P2P Loan Token holders at the respective P2P LoanToken holder's digital asset addresses associated with the Ether Walletholding the P2P Loan Token.

P2P Loan Token holders may then use the SVCoin as a digital asset toconduct other transactions. Eventually, the SVCoin can be exchanged forfiat at the exchange based on the notional value (e.g., 1 SVCoin=1dollar).

Example 9: Crowdfunding (CF) Tokens

In embodiments, a Crowdfunding service may issue a digital asset, suchas a token on the Ether Network (“CF Token”). As funds are collected, acorresponding amount of fiat is to be deposited with a digital assetexchange, such as a regulated digital asset exchange like Gemini. Thefiat is then converted into a SVCoin by the Exchange. The SVCoin maythen be distributed on a pro-rata basis (or as otherwise instructed bythe Crowdfunding service) to CF Token holders at the respective CF Tokenholder's digital asset addresses associated with the Ether Walletholding the CF Token.

CF Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notinal value (e.g., 1 SVCoin=1 dollar).

Example 10: Real Estate Crowdsourcing Tokens

In embodiments, a Real Estate Crowdsourcing services may issue a digitalasset, such as a token on the Ether Network (“RE Token”). As funds arecollected, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into a SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the Real Estate Crowdsourcing service) to RE Token holdersat the respective RE Token holder's digital asset addresses associatedwith the Ether Wallet holding the RE Token. RE Token holders may thenuse the SVCoin as a digital asset to conduct other transactions.Eventually, the SVCoin can be exchanged for fiat at the exchange basedon the notional value (e.g., 1 SVCoin=1 dollar).

Example 11: Artistic/Digital Rights Payment Tokens

In embodiments, tokens may be issued against an artistic work, such as asong or movie (DR Token), for example, as a token on the Ethereumnetwork. As royalties are collected for use of the song or movie, acorresponding amount of fiat may be deposited with a digital assetexchange. The fiat may be converted into SVCoin and distributed on apro-rata basis to the rights holders who are DR Token holders. Morespecifically, the SVCoin may be transferred the digital asset addressassociated with a wallet of a DR Token holder as a payment of royalties.

In embodiments of the examples discussed above, the token holders mayinstigate payment of SVCoin by sending a request for payment. In thiscase, any transaction fees will be the responsibility of the tokenholder. In embodiments, the token issuer, or an agent thereof, mayimplement or instruct distribution of payments in which case transactionfees are the responsibility of the token issuer.

Now that embodiments of the present invention have been shown anddescribed in detail, various modifications and improvements thereon canbecome readily apparent to those skilled in the art. Accordingly, theexemplary embodiments of the present invention, as set forth above, areintended to be illustrative, not limiting. The spirit and scope of thepresent invention is to be construed broadly.

What is claimed:
 1. A method of issuing electronic payments using astable value digital asset token on a digital asset security tokencomprising the steps of: (a) providing a digital asset security tokendatabase stored on a first set of one or more computer readable mediaassociated with a digital asset security token issuer system associatedwith a digital asset security token issuer, wherein the digital assetsecurity token database comprises a log of digital asset security tokensincluding: (i) a first set of digital asset addresses including arespective digital asset address for each respective digital assetsecurity token holder; and (ii) a respective digital asset securitytoken amount associated with each respective digital asset address,wherein each respective digital asset address of the first set ofdigital asset addresses is tied to a distributed public transactionledger maintained by a plurality of geographically distributed computersystems in a peer-to-peer network in the form of a blockchain; (b)providing a stable value digital asset token database stored on thedistributed public transaction ledger maintained by the plurality ofgeographically distributed computer systems in the peer-to-peer networkin the form of the blockchain, wherein the stable value digital assettoken database comprises a log of stable value digital asset tokensincluding: (i) a second set of digital asset addresses including asecond respective digital asset address for each respective stable valuedigital asset token holder; (ii) a respective stable value digital assettoken amount for each respective stable value digital asset tokenholder, wherein the stable value digital asset tokens are issued by astable value digital asset token issuer using a digital asset exchangecomputer system associated with a digital asset exchange; (c) receiving,by the digital asset exchange computer system, a first request from thedigital asset security token issuer system to purchase a first sum ofstable value digital asset tokens in exchange for a second sum of fiat,wherein the first sum corresponds to the second sum based on a fixednotional amount; (d) verifying, by the digital asset exchange computersystem, the first request, including: (i) verifying, by the digitalasset exchange computer system, that the digital asset security tokenissuer is a registered user of the digital asset exchange; and (ii)verifying, by the digital asset exchange computer system, that thedigital asset security token issuer has at least the second sum of fiatavailable for transaction with the digital asset exchange as reflectedin a fiat ledger of the digital asset exchange computer system; (e)accessing, by the digital asset exchange computer system, the digitalasset security token database to determine: (i) each respective digitalasset address of the first set of digital asset addresses for eachrespective digital asset security token holder; and (ii) the respectivedigital asset security token amount associated with each respectivedigital asset address; (f) determining a respective payment amount instable value digital asset tokens to be made to each respective digitalasset address of the first set of digital asset addresses based at leastin part on the fixed notional amount, the first sum of stable valuedigital asset tokens and the respective digital asset security tokenamount associated with each respective digital asset address of thefirst set of digital asset addresses; (g) generating, by the digitalasset exchange computer system, transaction instructions for the firstsum of stable value digital asset tokens by updating the stable valuedigital asset token database to reflect the addition of new stable valuedigital asset tokens in the amount of the first sum and thecorresponding digital asset addresses associated with each new stablevalue digital asset token; (h) transferring, by the digital assetexchange computer system, the second sum of fiat on the fiat accountledger from the user account of the digital asset security token issuer,to a custodial account of the digital asset exchange associated withstable value digital asset tokens, wherein the digital asset exchangecustodial account will maintain in trust a fifth amount of fiatcorresponding to a sixth amount of stable value digital asset tokensoutstanding based on the fixed notional amount; (i) publishing, by thedigital asset exchange computer system to the blockchain, transactioninstructions associated with crediting the respective payment amount ofstable value digital asset tokens to each respective digital assetaddress of the first set of digital asset addresses where ownership ofeach digital asset security token remains the same; (j) notifying, bythe digital asset exchange computer system, each digital asset addressof the first set of the digital asset addresses of each respectivetransfer of stable value digital asset tokens to each respective digitalasset address of the first set of digital asset addresses.
 2. The methodof claim 1, wherein the blockchain is the Ethereum blockchain.
 3. Themethod of claim 1, wherein the blockchain is the Bitcoin blockchain. 4.The method of claim 1, wherein the digital asset exchange is a regulateddigital asset exchange.
 5. The method of claim 1, wherein the digitalasset security token is a security registered with a governmentauthority.
 6. The method of claim 1, wherein the digital asset securitytoken is a debt security and the electronic payments are interest. 7.The method of claim 1, wherein the digital asset security token is anequity security and the electronic payments are dividends.
 8. The methodof claim 1, wherein the digital asset security token is secured byintellectual property rights and the electronic payments are royalties.9. The method of claim 1, wherein the blockchain is based on amathematical protocol for proof of work.
 10. The method of claim 9,wherein the mathematical protocol is open source.
 11. The method ofclaim 1, wherein the blockchain is based on a mathematical protocol forproof of stake.
 12. The method of claim 11, wherein the mathematicalprotocol is open source.
 13. The method of claim 1, wherein theblockchain is based on a cryptographic mathematical protocol.
 14. Themethod of claim 1, further comprising a step of publishing, by thedigital asset exchange computer system to a side ledger, the transactioninstructions associated with crediting the respective payment amount ofstable value digital asset tokens to each respective digital assetaddress of the first set of digital asset addresses and the publishingstep (i) includes publishing the transaction instructions from the sideledger to the distributed public asset ledger periodically oraperiodically.
 15. The method of claim 1 further comprising steps of:receiving, at the digital asset security token issuer system, from atleast one digital asset security token holder, a payment request priorto the receiving step (c), the payment request including: (i) thedigital asset address of the at least one digital asset security tokenholder; and (ii) a request to transfer a payment amount of stable valuedigital asset tokens to the digital asset address of the at least onedigital asset security token holder; confirming, at the digital assetsecurity token issuer system, that: (i) the digital asset address of theat least one digital asset security token holder is valid; (ii) thedigital asset security token amount of digital asset security tokensassociated with the address of the at least one digital asset securitytoken holder is more than zero; and (iii) the at least one digital assetsecurity token holder is entitled to payment; and generating, at thedigital asset security token issuer system, the first request based atleast in part on the payment request when the digital asset address ofthe at least one digital asset security token holder is valid, thedigital asset security token amount of digital asset security tokensassociated with the address of the at least one digital asset securitytoken holder is more than zero and the at least one digital assetsecurity token holder is entitled to payment.
 16. The method of claim 1,wherein the digital asset security token database is maintained andstored on the plurality of geographically distributed computer systemsin the peer-to-peer network in the form of the blockchain.
 17. Themethod of claim 1, wherein the digital asset security token database ismaintained on a sidechain, separate from the blockchain, whereininformation on the sidechain is published and stored on the blockchainperiodically or aperiodically.
 18. The method of claim 1, wherein thegenerating step (g) includes generating, by the digital asset exchangecomputer system, transaction instructions for the first sum of stablevalue digital asset tokens by updating the stable value digital assettoken database to reserve stable value digital asset tokens in theamount of the first sum.
 19. The method of claim 1, wherein the paymentinformation relates to a dividend to be paid based on ownership of eachdigital asset security token.
 20. The method of claim 1, wherein thepayment amount relates to a royalty to be paid based on ownership ofeach digital asset security token.
 21. The method of claim 1, whereinthe payment amount relates to interest to be paid based on ownership ofeach digital asset security token.